Method and apparatus for broadcast communications

ABSTRACT

An interactive broadcasting system is arranged to receive and respond to user inputs in relation to broadcast material. A scheduler ( 1200 ) polls continuously for new user inputs and adjusts its scheduling appropriately, in accordance with algorithms. This might be for example to insert content from user inputs into a live or pre-recorded broadcast or to re-order elements of a broadcast, such as travel clips from a playlist. The system has many applications. Users can for example post messages or dedications, interact in discussion programmes, vote for clips from a playlist, request live feeds, enter competitions or make purchases. Optionally, the response of the scheduler ( 1200 ) can be time dependent, for instance changing algorithms or scheduled content at a particular time of day or day of the week. As well as the scheduler ( 1200 ), embodiments of the invention provide a broadcast assembly system for storing broadcast elements, processing user inputs and assembling broadcast elements in accordance with processed user inputs for broadcast communications. Embodiments of the present invention are not limited to dealing with single broadcast channels but can also be used to playout multiple interactive channels. Such multiple channels can share either content or user interactivity or each channel may be entirely different in what is broadcast.

The present invention relates to methods and apparatus for use inbroadcast communications. For instance, embodiments of the presentinvention relate to scheduling and/or assembling broadcast material.

Broadcasting in communications is the ability to transmit content fromone source to more than one delivery point, usually user apparatus suchas a radio, television, PDA or personal computer (“PC”), during the sametime period. As used in this specification, “broadcasting” includes forexample multicasting in which content can be delivered to a group of twoor more delivery points during the same time period, the group beingselected from a larger population of possible delivery points. It can bethe same content going to each delivery point or a different contentgoing to each delivery point as required.

In broadcasting, content may be transmitted from one or more broadcastcentres in the form of scheduled programmes. To receive a programme, auser selects a programme channel. Delivery of the programme to thedelivery point can nowadays be done in several different ways and mightuse for example one or more of television, radio, the Internet, mobiletelecommunications, local communication centres and/or other media.

Broadcasting tends to present a high entry cost to new broadcastersentering the market. The broadcast centres rely on bespoke systemarchitectures that are expensive to build and maintain, being speciallydesigned and built for the individual broadcaster or service provider.New companies who want to launch new channels must raise significantcapital sums to build, lease or outsource expensive broadcast facilitiesbefore they can start broadcasting and generating revenue. This highentry cost therefore limits competition in the broadcast market.

Broadcasting also tends to be inflexible. Television and radio channelsusually prepare their detailed programme schedules, what they willbroadcast and when, at least three weeks in advance. These schedules arethen made available via newspapers, magazines and electronic programmeguides (EPGs). If a user wants to receive a particular

programme he/she has to arrange their day around the broadcast scheduleor remember to preset their video/audio recorder.

Further, the flow of information in typical broadcast environments isone way. The broadcaster broadcasts the content to users. Any feedbackfrom users is derived for instance from ratings data. This data is basedon a statistically significant but generally small sample of users usingeither a hand written or electronic diary. The diaried ratings data isthen collected and processed by the broadcaster for use in futureprogramming decisions.

Up until recently, television channels have been tape based and havesimply provided “linear playout” in which programmes are broadcastaccording to a predetermined schedule. As the costs of mass storage camedown and the quality of encoding methods improved, systems started tomigrate from tape based to disk based systems. These systems were stillexpensive and for linear playback only.

As technology has further improved it has become possible to build PCbased systems for disk-based playout. These have been used for examplefor transmitting videos to users. Currently in the video playout marketthere are generally two kinds of PC based playback systems. The first isfor linear playback, equivalent to the earlier broadcasting systems. Thesecond is slightly more flexible. This is interactive video in whichselected video material can be requested by a user, for instance using atelephone-based Interactive Voice Response (“IVR”) menu. However,interactive video systems are still expensive to provide and offer verylimited interactivity. They can also be complicated to use.

Although not broadcasting in the manner of traditional television,interactive video, “video on demand” and the like can be considered aform of broadcasting since content is in practice available to more thanone delivery point from the same source during the same time period.Either the same or different content may be available from the source toeach delivery point.

According to a first aspect of the present invention, there is provideda scheduling system comprising:

-   i) a scheduler for scheduling broadcast elements for broadcasting;    and-   ii) a user input data store for storing user input data    in which the scheduler is adapted to access the user input data    store and to schedule broadcast elements, the scheduling of one or    more broadcast elements being at least partially determined by    stored user input data.

The stored user input data might comprise one or more user inputsthemselves and/or data about the user inputs such as numbers of inputsreceived. For instance, the stored user input data might comprise one ormore of the following, depending on the nature of the interactiveservice being supplied at the time: votes or counted numbers of votes,requests for information, multiple choice selections such as answers toquestions asked of viewers, competition entries, purchasing information,and content for broadcasting such as clips, text messages, picturemessages and dedications. The data can take various forms, including butnot limited to numbers, text, graphics, pictures, audio and video, orany combinations of those.

The broadcast elements comprise material which will actually bebroadcast, either alone or together with other broadcast elements, andmay be long or short. For example, a broadcast element may be a shortpart of a programme, such as an introduction or closing passage, a videoor audio clip, or it might fill a programme break such as anadvertisement. Alternatively it could be part of a day or week'sbroadcasting, or part of a channel. A broadcast element may also bematerial which is to be shown at the same time as other material in abroadcast. For example, in a screen-based system it might be a piece oftext or artwork shown as an overlay, or a voiceover.

A scheduling system according to an embodiment of the invention mightfurther comprise an asset store for storing broadcast elements to bescheduled by the scheduler. These broadcast elements might be assembledfor storage from one or more of several sources. For example, storedbroadcast elements might comprise video and/or audio clips assembledfrom tape or disc, text or graphic overlays and prerecorded presentationmaterial such as run-ins, introductory and closing material.

Preferably, the asset store is adapted to store as “assets” schedulingcriteria as well as broadcast elements. Scheduling criteria may comprisedata and/or logic such as rules, algorithms and playlists for use indetermining how the scheduler deals with broadcast elements of differenttypes and/or at different times.

A user input might itself comprise one or more broadcast elements, suchas a message or dedication to appear on-screen. Alternatively oradditionally, a user input or stored user input data might simplyidentify one or more broadcast elements. For instance, the stored userinput data might comprise one or more votes or requests for broadcastelements, such as items from a playlist.

Broadcast elements identified by stored user input data might beinternal to the broadcasting system, for instance stored in thebroadcast element store, or at least one or more might be external tothe broadcasting system. Broadcast elements external to the system mightbe accessible by the broadcasting system but not stored or otherwisecontrolled by it. For example, an element that might be identified mightbe a live news feed provided by an independent broadcasting service.

Broadcast elements might be identified directly, for example by codesallocated to individual broadcast elements, or they might be identifiedindirectly, for example by a channel and perhaps time of dayinformation.

It is not essential that the scheduler is adapted to access the userinput data store directly. It might in practice receive user input datavia another device or other devices, or via other software.

The broadcasting system may further comprise a user input processor forprocessing user inputs. This might be adapted to process user inputs soas to produce user input data for storage in the user input data store,or to process user input data which has already been stored in the userinput data store. The processing done by the user input processor mighttake any one or more of various forms. For instance, the processor mightsort user inputs according to type so that they can for instance bestored according to type. Alternatively or additionally, the processormight be used to read, or at least recognise, content in the userinputs, for example to read and count votes or requests, or to read andassess competition entries or answers to questions. The processor mightbe adapted to recognise broadcast elements comprised by a user input.Preferably, the processor is adapted to provide a validating and/orediting facility for broadcast elements comprised by user inputs.

Preferably, the user input processor is connected to deliver processeduser inputs for storage in the user input data store for use by thescheduler in scheduling broadcast elements. The scheduling of one ormore broadcast elements may then be at least partially determined byprocessed user input data. For example, where the processor sorts userinputs according to type, the scheduler might schedule different typesdifferently, such as scheduling dedications so that they overlay arelevant clip but scheduling messages to appear on receipt withoutwaiting for a specific clip.

Where the processor is used to read content in the user inputs, thescheduling of one or more broadcast elements may be at least partiallydetermined by that content. For instance, where the processor is used tocount user input data such as votes or requests, the scheduling of oneor more broadcast elements may be at least partially determined by theresult of the counting, for example the number of votes or requestsreceived in respect of individual broadcast elements. Where theprocessor is used to assess user input data such as competition entriesor answers to questions, the scheduling of one or more broadcastelements may be at least partially determined by the result of theassessment, for example by scheduling a winning competition entry orcorrect answer to a question as a broadcast element. Alternatively, abroadcast element for scheduling might be constructed by processing userinput data, for instance by tabulation of user responses to a multiplechoice question.

One way in which scheduling might be determined is by setting a priorityor frequency with which a broadcast element is repeated. This would beparticularly appropriate for instance where the processor is used tocount user input data such as votes or requests for broadcast elementssuch as items from a playlist. The priority or frequency with which theitems are scheduled can be determined by the number of votes or requestsreceived in respect of the items.

Preferably, the scheduling system is provided with a first output forscheduled broadcast elements for broadcasting and a second output forprocessed user inputs and/or broadcast elements. The first outputpreferably comprising output from a scheduler of scheduled andunscheduled events according to predetermined requirements. This secondoutput offers the opportunity for the user inputs or broadcast elementsto be made available beyond a broadcast channel. For example, they couldbe made available via a website for access over a different andpotentially much longer period, if desired.

In use, an embodiment of the present invention is preferably connectedto one or more communication systems for use by users in providinginputs for storage in the user input data store. Such a communicationsystem might be a telephone network, a local area network, the Internetor any other suitable network but preferably it can receive and transmituser inputs in a format directly suitable for storage in the user inputdata store. For example, a mobile telephone network can receive andtransmit user inputs in the form of text messages which can be loadeddirectly to a user input data store. Similarly, data networks such as alocal area network or the Internet can receive and transmit textmessages.

In embodiments of the invention, as mentioned above a user input canitself comprise a broadcast element and this might be for instance inthe form of audio, text, pictures or graphics. Thus embodiments of theinvention can be designed to support on-screen (or on-air in the case ofaudio services) broadcasting of user generated messages. Users receivinga broadcast can interact with it in a number of ways, including but notlimited to sending messages for broadcasting to other users. In thisway, users can express their opinions in a broadcast for their peers toshare and comment on and can also dedicate broadcast content.

Thus embodiments of the present invention can be designed to support arelatively wide range of interactivity between a user and the broadcastsystem creating a stronger relationship between viewer and programme,daypart or channel.

The use of a scheduler responsive substantially in real time to selectand schedule programme elements is particularly advantageous. It can forexample provide flexible programming in direct response to user demand.For example, if the programme being transmitted follows a playlist, theplaylist can be altered in response to demand.

Preferably the system further comprises means to adjust the response ofthe scheduler to user inputs according to time period. The time periodmight be for example part of a day, in which case the behaviour of thescheduler can be altered at different times of day. However, the timeperiod might alternatively be part of a week, in which case thebehaviour of the scheduler can be altered on different days, for exampleat weekends.

The response of the scheduler might be adjusted in more than one way.Preferably, the scheduler is provided with at least one algorithm whichat least partially determines its response. The response of thescheduler can then be adjusted by changing the algorithm, or parametersused by the algorithm, according to time period. For example, userinputs might identify specific broadcast elements. It would be possiblethat the scheduler treats the user inputs as votes for viewing thosebroadcast elements at one time of day and treats them as votes fordiscarding those broadcast elements at another time of day.Alternatively or additionally, the algorithm might stay the same but theresponse of the scheduler might be adjusted by changing the broadcastelements it schedules in response to user inputs. For example, thescheduler might schedule broadcast elements from a specified playlist inresponse to user inputs and that playlist might be substituted, expandedor changed according to time period.

Embodiments of the present invention can also be designed to support awide range of different communication technologies for receiving userinputs, including not only IVR but also for example messaging (“SMS” or“MMS”), email and/or set top box formats.

According to a second aspect of the present invention, there is provideda broadcast assembly system for assembling broadcast elements forbroadcast, the system comprising an asset store for storing one or morebroadcast elements, and an asset processor for processing broadcastelements, wherein the asset store, in use, stores at least one rule oralgorithm for use in assembling broadcast elements for broadcast and theasset processor provides at least one tool for processing broadcastelements by editing.

In the broadcast assembly system, at least one stored rule or algorithmmay comprise a scheduling criterion for use in scheduling broadcastelements for broadcast. Such a scheduling criterion may comprise a ruleor algorithm for responding to at least one user input. This form of thebroadcast assembly system is of course particularly useful for use withembodiments of the invention in its first aspect. Alternatively, thebroadcast assembly system itself may comprise a user input processor.

Preferably, at least one stored rule or algorithm is time dependent.This can allow broadcast assembly to vary, depending on time of day, dayof the week, or even seasonally for example.

The broadcast assembly system might itself comprise a scheduler forassembling broadcast by scheduling, or it might be adapted for use witha separate scheduler. However, the separate scheduler would preferablybe capable of applying any scheduling criteria, for instance by having aspecified interface.

Preferably, the asset processor comprises means for creating ormodifying one or more broadcast elements and/or rules or algorithms.This provides a very flexible and versatile system.

A broadcast system according to the second aspect of the invention mightcomprise:

-   i) an asset store for storing broadcast elements;-   ii) a user input data store for storing user input data;-   iii) an asset processor for processing broadcast elements; and-   iv) a user input processor for processing user inputs,    wherein the user input processor is adapted to process user input to    provide user input data for storage in the user input data store and    the asset processor is adapted to process broadcast elements for    storage in the asset store.

As in the first aspect of the invention, the user inputs may themselves,in use, comprise one or more broadcast elements.

Embodiments of the invention in its second aspect can provide a powerfultool in the collection and processing of broadcast elements so that theycan be used in subsequent scheduling, however that subsequent schedulingmight be carried out. Hence this second aspect of the invention is veryclosely related to the first, much in the manner of a transmitter and areceiver. The second aspect of the invention can be used to assemblebroadcast elements and user input data for use by the scheduler of thefirst aspect of the invention.

The asset store, user input data store and the user input processoraccording to this second aspect of the invention may each be the same asthose according to the first aspect of the invention. For instance, justas in embodiments of the invention in its first aspect, the asset storemay store both broadcast elements and scheduling criteria.

The asset processor might comprise any one or more of the following:

-   -   an encoder for encoding broadcast elements into a format        suitable for broadcast, for instance encoding video material        into MPEG format    -   an editor for editing broadcast elements    -   a programming capability for programming scheduling criteria

It should be noted that the asset processor and the user input processormight in practice be embodied within the same software application, orthe functions representing the two processors might be distributedbetween two or more separate applications in any convenient manner.However, in general, the user input processor usually carries out itsfunctions during broadcasting while the asset processor usually carriesout its functions prior to broadcasting.

Embodiments of the invention also encompass a user input processor foruse with a broadcasting system as described above, having an input forreceiving user inputs, at least one processing tool for processingreceived user inputs, a first output for processed user inputs for useby the broadcasting system in scheduling broadcast elements and a secondoutput for processed user inputs. The second output may be adapted forconnection to the Internet. A user input processor of this type has theadvantage of using processed user inputs in more than one way and toreach more than one type of user. It is not essential that user inputsare processed in the same way for both outputs.

According to a third aspect of the present invention, there is provideda method of broadcasting, said method comprising the steps of:

-   i) receiving a list of broadcast elements;-   ii) receiving a user input relating to at least one broadcast    element, and-   iii) responding to the received user input.

A received user input might itself comprise at least one broadcastelement in addition to those listed. Step iii) might then comprise forexample broadcasting the additional broadcast element together with atleast one broadcast element from the list. Alternatively oradditionally, it might comprise re-ordering the list and/or outputting areply to the user input.

The list of broadcast elements might be received for example from anasset store as mentioned above, where the asset store is adapted tostore not just broadcast elements but also scheduling criteria, such asplaylists.

Such a method allows a broadcasting system to overlay content from userinputs onto elements of a prescheduled programme, such as items from asports video or music video clip list or an audio playlist.

Preferably the method further comprises the step of processing broadcastelements prior to broadcasting, for instance to encode material in aformat suitable for broadcast, such as MPEG, and/or to edit broadcastelements. The ability to edit broadcast elements is particularly usefulwhere broadcast elements can be received via user inputs and may notmeet broadcast criteria.

Preferably steps ii) and iii) can be performed in a relatively shorttime period, for example within a day or even within an hour. Morepreferably, steps ii) and iii) can be performed so as to provide asubstantially real time response to user inputs, for instance in tenminutes or less, or even in ten seconds or less.

Optionally, the additional broadcast element may have associated with itan identifier for a broadcast element present on the received list. Thisallows users to comment on, or dedicate, broadcast items such as sportsvideo clips or music video clips.

Preferably the method further comprises the steps of:

-   iv) receiving at least one user input identifying at least one of    the broadcast elements on the list; and-   v) generating an ordered list of broadcast elements from said list,    in accordance with the at least one user input.

Such a method allows a broadcasting system to respond to user input forinstance by moving an item further up a playlist in response to userrequest.

As more channels launch on digital television platforms, each newchannel will have more competition for both users and advertising andsponsorship revenue. To survive channels are likely to have to operateat as low a cost base as possible and to offer attractive services.Embodiments of the present invention can offer flexible, interactive andcost effective preparation and playout systems using a robust openarchitecture which is particularly suitable in this competitiveenvironment. They can also provide a particularly flexible approach tointegrating video and graphics on screen, and processes and algorithmsfor running both an interactive broadcast which responds substantiallyin real time to the user as well as a linear scheduled broadcast.

Embodiments of the present invention can also be used prior to playout,to manage a wide variety of broadcast elements from widely variedsources, including user inputs, processing them for instance by editingor validating them, and assembling them prior to scheduling togetherwith tools for use in that scheduling, such as playlists.

Thus according to a fourth aspect of the present invention, there isprovided a method of assembling broadcast elements for broadcasting,said method comprising the steps of:

-   i) processing at least one broadcast element and loading the    processed broadcast element to an asset store;-   ii) storing one or more rules or algorithms for use in assembling a    set of broadcast elements for broadcast; and-   ii) applying at least one of said rules or algorithms in assembling    a set of broadcast elements for broadcasting, including at least one    processed broadcast element.

A method according to this fourth aspect of the invention may furthercomprise receiving, via a user input, data relating to at least onebroadcast element. The step of applying at least one of said rules oralgorithms in assembling a set of broadcast elements may then be carriedout in accordance with received data.

The method may further comprise receiving, via a user input, at leastone broadcast element and an assembled set of broadcast elementscomprises at least one broadcast element received via a user input.

Further, the method may comprise the step of broadcasting an assembledset.

Preferably, embodiments of the present invention providing playout basedon one or more user inputs have a relatively quick response time. Theresponse time seen by a user making a user input is the response timebetween submission of the user input and response by the system to thenature of the user input. It is preferable that embodiments of theinvention have a response time between receipt of a user input by thesystem and response by the system to the nature of the user input of tenminutes or less. More preferably, the response time is two minutes orless. In some embodiments, the response time may be ten seconds or less.

The broadcast element is not necessarily actually broadcast within theresponse time. As long as the system has scheduled it, the response bythe system to the nature of the user input might take different forms.For example, the system might broadcast scheduling information about thebroadcast element or might transmit scheduling information in reply tothe user input.

Embodiments of the present invention may make some use of existinginfrastructure and technologies in order to reduce the costs ofconversion. They can offer a simple way of integrating existing hardwareand software components to create a comprehensive architecture,potentially with seamless redundancy.

An interactive system according to an embodiment of the invention may beused as extensively as the broadcaster requires and may be used forexample to broadcast an entire channel, 24 hours per day or for parts ofthe day, or to broadcast just one or more selected programmes. Anadvantage from the broadcaster's point of view is that as a result ofthe interactivity inherent in embodiments of the invention broadcastersand/or advertisers can potentially obtain continuous realtime feedbackfrom and about users. Depending on charging arrangements, it may also bepossible to provide interactive broadcasting as a chargeable service andthus receive revenues from user inputs for instance by charging inputcalls at a premium rate.

Embodiments of the invention do not necessarily include a broadcastfacility for outputting a broadcast. They can be designed to be flexibleenough to be adapted to, and physically connected to, a broadcastfacility. They can still provide something simple and easy to operate byusers to create interactivity which has not been previously availablewith for example an existing or independently provided broadcastfacility.

Glossary of Terms

The following terms have the following meanings as used in thisspecification:

-   AES/EBU A digital audio transfer standard named after the Audio    Engineering Society/European Broadcasting Union-   CLI Calling Line Identity-   DSL Digital Subscriber Line-   DVI Digital Video Interactive-   GPI General Programming Interface-   HDD Hard disk drive of a computer.-   IBS Interactive Broadcasting System-   IP Internet Protocol-   IVR Interactive Voice Response: a voice recognition system that    interacts with callers and is usually menu-based.-   Microsoft IIS Microsoft Internet Information Server MMS Multimedia    Message Service, feature of 2.5 G and 3 G cell phone technology-   Moderation screening user input for suitability-   MPEG Moving Picture Experts Group (video file formatting)-   PCI Peripheral Component Interconnect: an interconnection system    between a microprocessor and attached devices in which expansion    slots are spaced closely for high speed operation.-   PDA Personal Digital Assistant-   RAID Random Array of Inexpensive Disks, commonly comes in the    following configurations.-   RAID-0 has striping but no redundancy of data. It offers the best    performance but no fault-tolerance.-   RAID-1 provides disk mirroring and no striping. Read performance is    improved since either disk can be read at the same time. Write    performance is the same as for single disk storage. RAID-1 provides    the best performance and the best fault-tolerance in a multi-user    system.-   RAID-5 includes a rotating parity array so that all read and write    operations can be overlapped. RAID-5 stores parity information but    not redundant data (but parity information can be used to    reconstruct data). RAID-5 requires at least three and usually five    disks for the array. It's best for multi-user systems in which    performance is not critical or which do few write operations.-   RVIS Remote User Input Server-   SBS Scheduling Broadcast Server.-   SDI Serial Digital Interface-   SMS simple messaging or “Short Message Service”, feature of GSM cell    phone technology.-   SOAP Simple Object Access Protocol-   SQL Structured Query Language-   STB Set Top Box-   SVHS Super Vertical Helix Scan-   t1 line High capacity voice or data line-   VBI Vertical Blanking Interval-   VIS User Input Server-   VOD Video on Demand-   WiFi Interoperable Wireless Local Area Networks-   Wi-Max WiFi with extended connectivity-   XML Extensible Markup Language

Lastly, the “User Telephone Number” denotes a telephone number that theuser is calling or texting from and the “User Contact Number” denotes atelephone contact number displayed to users to send (call or text)messages and requests to a channel.

An interactive broadcasting system (DBS) according to an embodiment ofthe present invention will now be described, by way of example only,with reference to the accompanying figures in which:

FIG. 1 shows a schematic overview of the IBS;

FIG. 2 shows a schematic view of a system of encoding video for use inthe IBS shown in FIG. 1;

FIG. 3 shows a schematic view of a system of editing video andprogramming channels for use in the IBS shown in FIG. 1;

FIG. 4 shows a schematic view of a system of proofing content for use inthe IBS shown in FIG. 1;

FIG. 5 shows a schematic view of a system transferring proofed contentto scheduling broadcast servers for use in the IBS shown in FIG. 1;

FIG. 6 shows a schematic view of a system for moderating user inputs foruse in the IBS shown in FIG. 1;

FIG. 7 shows a schematic view of a system for transferring from a liveto a standby broadcast server for use in the IBS shown in FIG. 1;

FIG. 8 shows a schematic view of a system for archiving channelprogramming data for use in the IBS shown in FIG. 1;

FIG. 9 shows a schematic view of a system for remote management ofscheduling broadcast servers for use in the IBS shown in FIG. 1;

FIG. 10 shows a schematic view of a system for test and development foruse in the IBS shown in FIG. 1;

FIG. 11 shows a functional block diagram of user input processing andstorage for use in the IBS shown in FIG. 1;

FIG. 12 shows a functional block diagram of equipment for assemblingbroadcast streams, for use in the IBS shown in FIG. 1;

FIG. 13 shows a functional block diagram of a scheduler for use in theIBS shown in FIG. 1;

FIG. 14 shows schematically the layout of a screen showing visualmaterial which has been broadcast by the IBS shown in FIG. 1;

FIG. 15 shows a sample platform for supporting the IBS shown in FIG. 1;and

FIGS. 16 to 19 show schematic views of alternative deployments ofequipment of an IBS as shown in FIG. 1 for supporting multiple channels.

1. IBS OVERVIEW

The interactive broadcasting system is arranged to receive and respondto user inputs in relation to broadcast material. User inputs arereviewed on receipt, parsed and written to a database. A broadcastscheduler polls continuously for new user inputs and adjusts itsscheduling appropriately, in accordance with programmed algorithms. Thismight be for example to insert content from user inputs into a live orpre-recorded broadcast or to re-order elements of a broadcast, such astravel clips from a playlist. The system has many applications. Userscan for example post messages or dedications, interact in discussionprogrammes, vote for clips from a playlist, request live feeds, entercompetitions or make purchases. Optionally, the response of thescheduler can be time dependent, for instance changing algorithms orscheduled content at a particular time of day or day of the week. Theuser always receives an acknowledgement when communicating with thechannel.

Referring to FIG. 1, the interactive broadcasting system (IBS) isprovided primarily across three domains:

-   -   a network provider's domain 100    -   an IBS provider's domain 105    -   one or more broadcast hosting domain(s) 110, 115

The IBS broadcasts material to users 120 who can respond by makinginputs to the IBS via a communications network (not shown). The userinputs are received within a network provider's domain 100 and madeavailable to the IBS for use in modifying subsequent broadcasting. Animportant feature is that the IBS can give a substantially real timeresponse so that users see the result of their inputs almostimmediately. Another important feature is that content from user inputscan be shown on screen, for instance as a text overlay. This means thatusers can effectively communicate with each other using the screen, forinstance to make dedications or to send messages.

Each of the domains 100, 105, 110, 115 provides some IBS functionality(shown in each domain on FIG. 1 within a box) and some data storage(shown in each domain on FIG. 1 within a database symbol). In theembodiment described below, each of the domains 100, 105, 110, 115 isprovided with one or more servers which will support both softwareapplications to provide the functionality and databases to provide thedata storage.

It should be noted that the separation of the IBS between domains is notessential and that neither the distribution of servers, nor thedistribution of functionality and data storage, is essential. Indifferent embodiments, it may for example be possible to run the IBS ina single domain and on a single machine, such as a single server.Alternatively, any of the domains could be spread across severalmachines, or any two or more of the domains could share one or more ofthe same machines.

Although in the description below mySQL data storage is generallydescribed, various other databases can be used, including but notlimited to Microsoft Access, Oracle and SQL Server.

Broadcast transmissions reach users 120 in known manner and in thisembodiment it is via an output 101 from the broadcast hosting domain(s)110, 115 to an uplink 130 and satellite 125 although other transmissiontechnology might be used. For redundancy, at least two broadcastinghosting domains 110, 115 are preferably used and these provide live andstandby broadcast transmissions. It is however also possible tobroadcast with a single hosting domain 110.

There is also a second output 102 from the broadcast hosting domain(s)110, 115 and this goes to a website for “offline” presentation of IBSmaterial such as selected broadcast elements and/or processed userinputs. “Offline” in this context means not part of the broadcasttransmission from the first output 101.

Looking firstly at the network provider's domain 100, this providesfunctionality 150 for user input sorting and data storage 155 (referredto herein as the “RVIS” 155) for storing the sorted, raw user inputs. Tointeract with the IBS, users 120 make inputs using known communicationstechnology, such as a telephone network (not shown). The user inputs canbe of various types and these need to be sorted so that the IBS canrespond to the different types appropriately. For example, a user inputmight be a vote for an item on a playlist, an answer to a question or arequest that a message be broadcast. Again, user input sorting can bedone using sorting software and known database technology. For example,the user 120 might use a first telephone number for a vote and a secondtelephone number for a message request. Hence votes and message requestsare automatically sorted into their respective types by means of thetelephone connection they are received at. Similarly all user input canbe sent to a single mobile telephone short code and be sorted by theRVIS 150.

In more detail, the sorting software can sort the user input within thedatabase based on a number of criteria, which include but are notlimited to; the user input itself, the interactive service beingbroadcast at the time it is received, the range of valid user input, thetelephone number or SMS/MMS short code the input came in on andpotentially an identifier for the user who sent it. Once sorted, theuser input is placed in an appropriate table in the RVIS 150. If forexample the user input consists only of a three digit number and theinteractive service being broadcast is a voting service, then the userinput will be deemed a vote.

The sorted, raw user inputs are stored in the RVIS 155 in the networkprovider's domain 100. They can be delivered from there to one or moreappropriate location(s) in the IBS. In this embodiment of the invention,user inputs are delivered to a server 175 (referred to herein as the“VIS” 175) in each of the broadcast hosting domains 110, 115, both liveand standby. Requests and votes can be used for scheduling at thebroadcast hosting domains 110, 115. However, message requests arereviewed using moderation equipment in the IBS provider's domain 105where for example the content can be screened. Moderated messagerequests are then also stored in the VIS 175 in each of the broadcasthosting domains 110, 115 and used in scheduling.

Looking secondly at the IBS provider's domain 105, this provides a majorpart of the functionality 160 for managing the IBS, preparing broadcastcontent for scheduling and programming the criteria(rules/algorithms/dayparts) used in scheduling. It also provides datastorage, referred to herein as the “Storage Server” 165, to support thisfunctionality. In broad terms, the IBS provider's domain provides IBSmanagement overall, plus an “asset manager” comprising an asset storeand an asset processor. “Assets” in this context are firstly broadcastelements, however sourced, and secondly the scheduling criteria. Theasset processor provides one or more tools for assembling broadcastelements and scheduling criteria, such as encoding, editing andprogramming tools.

In particular, the functionality provided in the IBS provider's domain105 includes:

-   -   encoding material for broadcast    -   broadcast programming    -   proofing content and promotion to live    -   remote management of functionality and associated data in the        broadcast hosting domains 110, 115    -   monitoring, and moderating user messages    -   format development

Looking thirdly at the broadcast hosting domains 110, 115, each of theseprovides functionality 170 including a scheduler 1200, for schedulingbroadcast material which shows a real-time response to user inputsreceived at the network provider's domain 100. The scheduler 1200 canmake programming decisions at the moment of broadcast, based on rules oralgorithms that weight a number of factors including for example:

-   -   user inputs    -   playlist contents    -   time of day    -   previously broadcast material

In overview, the IBS as described below has the following aspects inuse:

-   -   broadcast asset management    -   connectivity for receiving user inputs    -   user input processing    -   responsive scheduling of broadcast elements    -   broadcasting the broadcast elements        together with tools for selecting and amending its behaviour. It        can be described as comprising a broadcast asset manager, user        input processor and a scheduler, where the asset manager stores        and prepares the broadcast elements and scheduling criteria and        the user input processor can provide any one or more of several        processes such as sorting, parsing, displaying for review,        counting, validating and/or forwarding of user inputs. It should        be noted that these user input processes are not necessarily        provided in one piece of software or application and they may        well be present in more than one of the domains 100, 105, 110,        115 and even for example within an application which otherwise        provides the scheduling.

The IBS as described above has an architecture based on a combination ofhardware and software systems and a secure hosting environment at thebroadcast hosting locations 110, 115 to operate the broadcast. Thearchitecture is an open architecture with interfaces for integratingdatabases, telecommunications, monitoring and signal transport.

Although only one broadcasting system is shown in FIG. 1, thearchitecture is sufficiently flexible to support multiple interactivebroadcast channels at the same time. For example, a set of channels canbe supported which are different in terms of: broadcast hours, content,language, territory of broadcast, supported interactivity anddistribution method.

Each of the three domains mentioned above is now described in moredetail.

2. NETWORK PROVIDER'S DOMAIN 100

Users 120 can interact with broadcast material by sending in requests,answers to questions, requests for information, purchasing informationfor a product, votes and messages, the messages containing text and/orpictures. This can be done using standard communications such astelephony, SMS, Internet, a set top box, a voice recognition system orother communications systems. User inputs are received at the networkprovider's domain 100 where they are stored as data on the “RVIS” 155.

The network provider allocates specific telephone numbers and/or otheraddresses to enable users to send input. These numbers and otheraddresses are published, for example by broadcasting or by other meanssuch as advertising. Such numbers/addresses allow user inputs to besorted into types. For example, a first number or address might beallocated to requests and votes while a second number or address can beallocated to messages. Everything received at the first number oraddress can be stored in the RVIS 155 as a request or vote (requests andvotes can be treated as the same at this stage) while everythingreceived at the second number or address can be stored in the RVIS 155as a message. Alternatively, a single telephone number or short code canbe used for all user input and it will be sorted into types by the RVIS150.

Ultimately, the user inputs are to be used in relation to a particularbroadcasting channel. It is preferable that each channel has an RVIS 155dedicated to it for the duration of the interactive service in relationto that channel. Preferably also, telephone numbers and/or otheraddresses allocated by the network provider to receive user inputs arespecific to the RVIS 155 which will deal with the appropriate programme.

User inputs will have content which is formatted according to the typeof input. In an example of a programme which might be broadcastinteractively, there may be a playlist of music, sports, travel, adultor other video clips. Users 120 might be invited to submit requests orvotes in relation to the video clips. Alternatively or additionally,users 120 might be invited to submit messages or dedications, answers toquestions, requests for information, bids for products being sold, votesfor a highlights programme or votes to see specific informationbroadcast. The content of these different types of user input in anexample of an IBS service might be as follows:

1. Requests

At any time that the service is being offered, the user 120 can submit arequest which identifies a clip from a playlist. The IBS response, oncethese have been processed, might be to change the order or frequency ofthe individual clips. A request is formatted to contain a code such as anumber with a predefined number of digits (eg 2, 3, 4 or more) whichidentifies the clip.

2. Votes

The service identifies a specific time slot in which the user 120 mustsend an input. There may be a voting deadline after which no furthervotes will be accepted and after which users should be given a messageto indicate that the voting period is over. A vote is formatted, like arequest, to contain a code such as a number with a predefined number ofdigits which identifies the clip. The vote can be a positive or negativevote for a particular clip to be broadcast or in the case of a shoppingservice a vote to see a particular product.

3. Text and Picture Messages and Video Messages

At any time that the service is being offered, the user 120 can submit amessage for broadcasting together with the content that happens to beplaying at the time. A message can contain text and/or pictures. Amessage is formatted to contain a text string and/or a picture and/orvideo. (The message length may be restricted for programming, technicalor editorial reasons, whether or not the message is deemed appropriate.)

4. Dedications

At any time that the service is being offered, the user 120 can submit amessage for broadcasting together with a specific video clip. That is,the message will only be broadcast while the clip is being played orshown. A dedication is formatted to contain a code (as described above)which identifies the clip, plus a text string and/or a picture.

5. Answers to Questions

At any time that the service is being offered, the user 120 can submitan answer to a question, either as part of a live broadcast or as acompetition. The aggregate answers to the question asked of the audiencecan be displayed during a live broadcast for the viewers to see or inthe case of a competition, the individual winners names will bebroadcast at a predetermined future time. An answer to a question cantake the form of a letter (a, b . . . ) in the case multiple choicequestions or words or numbers, depending on the exact question.

6. Request for Information

At any time that the service is being offered, the user 120 can submit arequest for information about a product or programme. This applies forinstance in the case of a shopping service, where a viewer would likemore information about a specific product or a programme based servicewhere the viewer requests more information about a programme, such aswhen it will be broadcast. The viewer may also subscribe to a servicethat reminds them when the programme will be broadcast and updates themwith news about the programme and its cast. The response to the questionwill typically be in the form of a reply text message. It could also bein the form of an email or other communication method.

7. Requests to Purchase Products or Bids for Products being Sold

At any time that the service is being offered, the user 120 can submit apurchase request or bid for a product being sold. This may apply in thecase of a sale, auction or bid based shopping service or other servicefor providing goods and/or sevices, where a viewer would like to place abid for a specific product. The bid will only be accepted while theproduct is being sold. The response to the bid will typically be in theform of a reply text message. It could also be in the form of a phonecall or other communication method.

8. Moves in a Single or Multiplayer Game

At any time that the service is being offered, the user 120 can submit amove in a game. This applies in the case of a single or multiplayer gamethat is being broadcast on the charmel. The move will only be acceptedwhile the particular game is being played. The response will depend onthe game being played but will typically have two parts, seeing aresponse on the television screen and a reply text message. It couldalso be in the form of a phone call or other communication method.

9. avi/wav File or Web Cam Stream

At any time that the service is being offered, the user 120 can submit alive or pre-recorded avi/wav file or web cam stream to be combined withthe broadcast at the time it is sent or at a later point in time lateron. (An avi/wav file or web stream is formatted to contain videoinformation.)

Preferably the network provider will collect at least the following datafor each user input:

-   -   i) the number or address the user input was received at and the        client to which it is assigned;    -   ii) the full telephone number (“CLI”) the user input was        received from, where available;    -   iii) the content, such as the identifying code and/or text        string and/or picture;    -   iv) the time of day and date; and    -   v) the length of the call (where applicable).

In the above, requests and votes are described separately. However, theycan be stored together in the RVIS 155 as long as the time of receipt isalso stored. This is because it is the mode in which the IBS service isoperating at the time of receipt which determines whether a user inputis a request or a vote. It is not necessary that the mode is known atthe network provider's domain 100. Instead, these user inputs willsimply trigger a different response from the IBS service, depending ontheir time of receipt and the mode the service was operating in at thattime of receipt. This is determined by the scheduler 1200 in thebroadcast hosting domain(s) 110, 115.

In the above, user inputs are sorted into types by means of the numberor address they were received at. However, an alternative method ofsorting is to review the format of the content. For example, a vote orrequest is a three digit number, a message will be just a text stringand/or a picture while a dedication contains a three digit number and atext string and/or picture. User inputs can thus be sorted into threetypes according to content format. If a user input does not adhere to apre-defined message type (which has been published or otherwise madeknown to users 120) then it is not processed by the IBS. Regardless ofhow a user input arrives, for example by telephone or email, a validinput can be analysed and stored correctly in the RVIS 155.

It might be noted that the formats described above should not beregarded as an exclusive list. Other formats might be found appropriateto support other forms of service.

The sorted user inputs stored as data in the RVIS 155 are subsequentlytransferred to databases 175, 195 in the broadcast hosting location(s)110, 115, both live and standby. These databases are each referred toherein as a “VIS” 175, 195. It is not essential that the data is firststored in the RVIS 155. The network provider's domain 100 might operateto send user inputs directly to the VISs 175, 195 but this can give riseto queuing problems. Alternatively, the RVIS 155 and a VIS 175/195 mightbe incorporated in a common system.

Sorted user inputs are stored in the RVIS 155 by inserting rows into adatabase on the RVIS 155. If user inputs are received in another form(eg, XML over TCP/IP), then a pre-processor located on the RVIS 155 willhandle the input and convert it into database table. For instance theRVIS 155 might accept input via a TCP/IP service running on MicrosoftIIS which will decompose the XML, determine what type of input has beenreceived and insert the data into appropriate tables on the RVIS 155.

The RVIS 155 is configured to copy data in its user input tables to theVISs 175, 195 both live and standby. This is achieved using databasedistribution/replication to push user input as it arrives to the variousVIS databases 175, 195. This exploits a default mechanism to send userinput to each VIS 175, 195 asynchronously. Thus if a VIS isinaccessible, or merely suffers delays in peak traffic, the RVIS 155 wintemporarily queue the user input until it is available again.

Other means can alternatively be used to transfer data between the RVIS155 and the VISs 175, 195 such as an HTTP connection.

Since the RVIS 155 would be dealing with a number of channels, aconfiguration similar to the VIS 175 (described below) may be required.However, this activity is predictable and measurable and benchmarksshould show an acceptable system size. Whatever the configuration,however, disks should preferably be mirrored for resilience.

Preferably, transfer of data to the VISs 175, 195 is done over a WANnetwork (dedicated line or VPN over Internet) and possibly through afirewall. The distribution/replication may take place remotely from thenetwork provider's domain 100. Preferably the data transfer takes placeover a dedicated line. Preferably user input data can be restored incase of system or component failure in the network provider's systems.In the event that there is a failed transfer of data from the RVIS 155to a VIS 175/195 the process preferably is able to roll-back to thestate it was in before the transfer was attempted. Preferably atransaction log is maintained to prevent loss of data. Any failure ofdata transfer between the network provider's domain 100 and the VISs175, 195 should not affect the collection of user input. When the datatransfer process recovers, the data collected in the meantime can betransferred along with the original transfer.

Further functions which can be provided from the network provider'sdomain 100 are charging, feedback and login procedures.

Charges for users 120 of the IBS service may be set independently foreach service. For example, charges to the user for calling the IVR, SMSand MMS input can be set independently for the various different typesof input (request, vote, text message, picture message etc) and for eachseparate broadcasting channel. For example, one channel may offerrequests at 50 p, votes at 75 p and text messages at 99 p while anotherchannel may offer the same at 40 p, 55 p and 75 p. Preferably thenetwork provider's domain 100 monitors the amount charged for eachinteraction and passes it to an IBS database, provided for example onthe storage server 165 in the IBS provider's domain 105.

User Feedback and Confirmation—preferably, user inputs are validated asacceptable inputs (so that they are not asking for a non-existentservice, for example). Also preferably, users receive a confirmationmessage appropriate to the relevant user input, such as a recorded voicemessage if their input was made by voice. Preferably, any outgoingmessages to the user have the capacity to include a message such as areminder or an advertisement.

User Registration and Log-in—users may be required to register andlog-in for some personalised services. The network provider's domain 100may therefore need to interact with a user information dataset, probablya subset of data already at the site. This user information will need toaccept data from two directions:

-   -   a) update information from the user    -   b) personalised messages from the IBS to the user.

Registration and login are not necessarily provided by the networkprovider's domain 100. Where user inputs are made over the Internet, forexample, registration and login might more appropriately be provided bythe IBS provider's domain 105.

It will be understood from the above that the network provider's domain100 in this embodiment provides at least one of the user input processeswhich can collectively be regarded as a user input processor. Forinstance it provides sorting.

3. IBS PROVIDER'S DOMAIN 105

As mentioned above, this domain 105 provides a major part of thefunctionality 160 for managing the IBS, managing the broadcast assets(that is generally broadcast elements and tools/rules/algorithms forprocessing the broadcast elements, including dayparts) and preparingmaterial for scheduling in accordance with user inputs. This isdescribed below in six general areas, “3.1” to “3.6”.

In general, the IBS provider's domain 105 is supported by a network fortransfer of data and software, for instance using Ethernet technology210. Preferably transfer rates, both internal and external, will be atleast 100 Mbps. This will allow timely transfer of files, though notreliable video streaming across the network.

3.1 Encoding Content for Scheduling

Referring to FIGS. 1 and 2, in the embodiment being described here,broadcasts transmitted by the IBS primarily comprise MPEG-2 video,MPEG-4 video or other encoded data which can be sent directly to a cablehead or satellite uplink 130 and broadcast in known manner to deliverypoints such as televisions, mobile phones or PCs in users'homes/premises. In order to encode and store content, the IBS provider'sdomain 105 is equipped with a video player 200, a workstation 205 havinga HDD for running software 160, and the storage server 165, and thesetaken together support what is referred to herein as broadcast assetmanagement.

FIG. 2 shows one system of encoding video, namely transferring videodata from digital or analogue tape run on the video player 200 to MPEG-4file format on the HDD of a networked workstation 205. This involves:

-   -   1. Encoding video material from a video player 200 on to the        local workstation HDD 205;    -   2. Storing encoded video and audio data files on one or more        networked storage servers 165;    -   3. Validating the files; and    -   4. Transferring the validated files to DVD or other portable        medium.

Transfer of data in this manner is relatively easy to do and there isstandard software available such as Operating systems copy utilities, orAdobe Premiere provided by Adobe Systems Inc.

Data is transferred from DVD or tape to the networked storage servers165 via the workstation HDD 205. A mySQL database on the storage servers165 is updated with pointers to the new video files stored. Given thetime taken to transfer video files and to manipulate them, an entry inthe mySQL database should be recorded for each file when transferstarts, and a status flag updated as it completes transfer. All encodedfiles are stored on the storage server(s) 165 while those required forbroadcast during a specific time period (day, week or month) are storedon the broadcast servers 180, 185 as well.

It is of course important to map the codes which are used in user inputsto the files which the codes identify. This mapping is held in a masterclip database on the storage server(s) 165.

3.2 Broadcast Programming

Referring to FIG. 3, there is shown one system of programming abroadcast which is another aspect of broadcast asset management.Programming a broadcast comprises:

-   -   selecting and editing content to go in the broadcast (scheduled        and unscheduled), including for example one or more playlists of        video clips    -   weighting the clips making up each playlist so that individual        clips will be repeated at an appropriate frequency in the        absence of user inputs    -   selecting or writing one or more algorithms for determining the        response of the IBS to user requests and/or votes.

Programming thus comprises the steps of:

-   -   1. Retrieving MPEG video material from the storage server 165 to        the HDD of the workstation 205    -   2. Editing the video material using known editing software such        as Avid Xpress (Trade Mark of Avid Technology Inc)    -   3. Selecting and weighting one or more playlists    -   4. Selecting or writing one or more algorithms for determining        the response of the IBS to user inputs    -   5. Selecting or writing proforma broadcast elements such as        tables or game presentations

In this context, editing means editing the actual clips to comply withprogramming issues such as time constraints or the watershed (forexample sometimes two versions of a clip are required for showing beforeand after a particular time of day).

Video files are retrieved from the storage server 165 and edited locallyon the workstation 205. A status flag in the mySQL database on thestorage server 165 noting that the file has been ‘checked out’ should beset. This shows that it is being worked on as a warning against anyoneelse doing the same. In addition, the status flag could be set to an‘approved’ or ‘ready for broadcast’ when editing is complete.

In addition, playlists and algorithms are created and updated within themySQL database on the storage server 165. These, again, should have astatus flag which can be set to show their stage of readiness.

A novel type of broadcast element that might be created or edited hereis the proforma broadcast element. Preferably a proforma broadcastelement is prepared in advance of broadcast with the intention that itmay be modified or acted upon with user input or other input prior toand/or during broadcast. One of the possible applications of embodimentsof the invention is to present processed user inputs in tabular form,for example the results of a competition or voting process.Alternatively, user inputs could be applied to an interactive game,creating broadcast elements which show a game format, updated during abroadcast to show the latest moves by the protagonists. Proformabroadcast elements can be created here and supplied to the broadcasthosting domain 110, 115 for update, according to an appropriatealgorithm, by the scheduler 1200.

A preferred feature of embodiments of the present invention is the useof dayparts. This is a technique for changing the response of thescheduler 1200 delivering a broadcast according to the time of day.Preparation of the daypart programming is also done in the IBSprovider's domain and can be incorporated in the algorithms mentionedabove. Examples of possible algorithms are further discussed below.

3.3 Proofing Content and Promotion to Live

Referring to FIG. 4, there is shown one system of proofing preparedmaterial and programming decisions in an environment nearly identical tolive production. Proofing is preferably an integral part of theproduction chain. In order to carry out proofing, the IBS provider'sdomain 105 comprises a proofing server 400 and a closed circuit monitor405.

Proofing comprises the steps of:

-   -   1. Retrieving relevant video material from the storage server        165 and loading it to the proofing server 400    -   2. Retrieving relevant playlists and algorithms from the storage        server 165 and loading them to the proofing server 400    -   3. Starting a copy of the scheduler 1200 that will run at the        broadcast hosting domain 110 during live transmission, on the        proofing server 400    -   4. Viewing output on the closed-circuit monitor 405    -   5. Making any changes necessary    -   6. Approving the relevant material, playlists and algorithms for        promotion to live and standby broadcast servers 180, 195 in the        broadcast hosting domains 110, 115.

Proofing is a process which tests not just content but also that theplaylists, algorithms and dayparts all work correctly.

The proofing server 400 may be a scalable copy of the productionbroadcast server 180. Multiple channels may share a proofing server 400.The resilience of the production broadcast servers 180 is less criticalsince all data can be reconstructed from the storage servers 165(depending on the acceptable down time whilst recovery is performed).There may be multiple proofing servers 400 depending on the number ofchannels which require proofing around the same time window.

Data is preferably copied to the proofing server 400 from the storageservers 165 for checking prior to transmission. Once proofed, data maybe copied to the live and standby broadcast servers 180, 185 for thechannel. After this, the environment can be removed if necessary.

In one embodiment, content may be copied from the live and standbybroadcast servers 180, 185 to replicate the production broadcast serversand files to help with problem diagnosis or to trial online fixes, datapatches, reproduce bugs, simulate broadcasts, and test new content andfunctionality.

Video files and mySQL database content are copied to the proofing server400. Files can be copied via standard Windows file copyingmechanisms—these can be shared between multiple channels which mayutilise the proofing server 400. The database content can be copied viaa subroutine. This would then copy the contents of tables into thecorrect form from the mySQL database on the storage server 165 to adedicated database for each channel on the proofing server 405. Thesubroutine would be preconfigured to ensure that only items which areready were copied, as required. In fact, the subroutine could beconfigured to return an error status if everything wasn't marked‘ready’.

Proofing is then carried out using the closed circuit monitor 405.Referring to FIG. 5, once the relevant material, playlists andalgorithms have been approved for promotion to live and standbybroadcast servers 180, 185 in the broadcast hosting domains 110, 115,the promotion can be carried out. This will be done by transferringapproved video, audio and other data files from the proofing server 400to the live and standby broadcast servers 180, 185. Transfer comprisesthe steps of:

-   1. Identifying approved (proofed) content for promotion on the    proofing server 400-   2. Making sure the live broadcast server 180 is ready to receive    data-   3. Initiating transfer to the live broadcast server 180, using for    example a leased line or DVD with on-site installation-   4. Verifying complete and error-free transfer-   5. Once transfer to the live broadcast server 180 is complete,    initiating data transfer to the standby broadcast server 185 and    repeating steps 3 & 4.

Data transfer can potentially occur even whilst a broadcast server 180is being used for broadcasting. The proofing server 400 shouldpreferably contain at least files which need to be added to a currentset on the broadcast server 180 to play the next schedules, and thestorage server database 165 should preferably contain both the newschedules and those currently playing.

As described above, the broadcast servers 180, 185 are updated in theorder live followed by standby. They may be updated at the same time orit may be preferred that the standby broadcast server 185 is updatedfirst. The latter arrangement has the advantage that if a problemoccurs, it can be detected on the standby broadcast server 185 and won'taffect the live broadcast server 180. To minimise risk further, oncefiles and database tables have been copied to the standby broadcastserver 185, a cycle of selecting and starting to play a video shouldpreferably be undertaken on the standby broadcast server 185 before theitems are copied to the live broadcast server 180.

For each broadcast server 180, 185, new video files may be copied viaWindows file copy to the broadcast server 180, 185. Then databasetables, which contain static control information such as the algorithmsand programme playlists (ie. all except logging tables), may be updatedfrom channel-specific database tables on the proofing server 400, forexample by using a mySQL subroutine. This resets the tables in questionto be identical to those on the proofing server 400.

This illustrates why it is preferred that the proofing server 400 shouldcontain the current schedules in addition to the new ones. Any emergencyupdates to the broadcast server 180 should preferably be reflected backto a database on the proofing server 400 prior to this replication.

Any queries currently under way on the broadcast server 180 will use anold copy of the tables even if a mySQL subroutine is underway. Once thequery completes, the next query will use the new copy of the databasetables. This can also be handled via a mySQL subroutine.

Playlists can be maintained for example by programmers, and updated asand when required, perhaps at regular intervals.

In addition to this mySQL copying, file copies may be used to add extramedia files to the broadcast server 180 which are referenced in theplaylists. At this stage, any that are not required on the new orcurrent playlist can be removed (this could also be done at any pointafter the new playlist kicks in). The storage media, for example a disk,should contain sufficient space to accommodate the total composite filelist from two playlists. (Storage media may of course need to be testedto ensure that it is possible to write new files to the disks whileexisting ones are playing.)

3.4 Remote Management of the Functionality 170 and Associated Data 175,180 in the Broadcast Hosting Domains 110, 115

Referring to FIG. 9, it may be preferred that functionality and data atthe broadcast hosting locations 110, 115 can be managed from the IBSprovider's domain 105. For instance, preferred management functions tobe carried out remotely, from the IBS provider's domain 105, might bechanging playlists, programme rules, user input rules or algorithms,daypart definitions etc.

A suitable system for remote management comprises the steps of:

-   1. Securing log-in to a workstation at the IBS provider's domain 105-   2. Finding a relevant broadcast server 180 on a remote network-   3. Making required changes and adjustments to programming or the    server 180-   4. Repeating steps 2 & 3 for the next relevant broadcast server 180-   5. Logging off the workstation.

A programming control application at the IBS provider's domain 105 canbe used to interact directly with the live broadcast server 180 and/orfunctionality 170. (In practice the functionality 170 may be run on thebroadcast server 180.) All such access will be via mySQL subroutinesand/or wrapped in database stored procedures. Any changes will be copiedto the standby broadcast server 185 using mySQL subroutine copying.

3.5 Monitoring, and Moderating user Inputs

The IBS provider's domain 105 also comprises (1) a monitoring section,to monitor the proper operation of the IBS and to intervene as and whenit is appropriate to maintain its operation, and (2) a moderationsection to moderate the text and pictures received from users. ITC andother regulations require that anything broadcast by a channel meettaste and decency requirements. Accordingly, all user data can bemoderated and any inappropriate material removed prior to broadcast.

Preferably, all user input will be moderated on a 24/7 basis. Usersexpect to see their messages within a relatively short period of time orlose interest. Accordingly, it is desired that the system provide theappropriate response within a short time frame. User input transferrates should be sufficiently fast to enable timely transfer of data suchthat moderation can occur immediately and to ensure that time-sensitiveuser input is processed and queued for broadcast within seconds.Preferably, no more than 10 seconds should elapse from the time the userinput is received to the moment it is available for moderation. All userinput should be logged and archived, including moderation decisions.Archives of user input may be removed from the system on a regularbasis, well before they grow in size to affect disk space. A regularschedule should be implemented to retrieve archives.

Referring to FIG. 6, as described above, user inputs are received in thenetwork provider's domain 100 and formatted into data files or mySQLtables which are stored as raw user inputs in the VIS 175. A system formoderating user inputs comprises the steps of:

-   1. Viewing the raw user inputs as data files/database table contents    at workstations 600 in the IBS provider's domain 105-   2. Moderating the user inputs—approve or delete-   3. Storing approved user inputs in the VISs 175, 195 in the live and    standby broadcast hosting locations 110, 115 for use in broadcasting

Once raw user input has been successfully copied to the live VIS 175,then moderator software in the IBS provider's domain 105 reads this datadirectly from the VIS 175. At this point, the user input is ready formoderation. Once moderated, the user input is inserted to a second setof tables in the live VIS 175 that are accessible in the IBS provider'sdomain 105 for playlist decisioning.

The moderator software can be run on a storage server 165 in the IBSprovider's domain 105 but may also be accessible over the Internetthrough a Web-based application. This allows the workstations 600 inpractice to be located wherever might be convenient.

All access to the live VIS 175 by the moderator software, for instanceconsequent to changes made using the workstations 600, occurs via mySQL.All modifications to the live VIS 175 are copied to the backup VIS 195using a mySQL subroutine. This ensures that the VISs 175, 195 are inline with each other ready for failover (described below) as required.

As well as the above monitoring and moderation, logs may be downloadedat predetermined intervals from the broadcast servers 180, 185 forreporting. For example the logs may be used for regulatory compliance(as played log), advertisers (as played log), or for internal analysis(interaction log).

Many broadcast and communication systems operate with latin charactersets only. It is preferred in embodiments of the present invention thatuser inputs can be received and used in other types of character set,such as those supporting right to left as well as left to rightlanguages and including, but not limited to, Chinese, Cyrillic, Hebrew,Arabic and like character sets. To achieve this the character sets mustbe supported throughout the system, from the RVIS which receives theoriginal user input, to the VIS where the input is moderated to the IBSwhere the user input is broadcast. At the RVIS and VIS the sortingsoftware and database must support the character set. At the IBS, thedatabase, scheduling and broadcast software must support it.

3.6 Development

A test and development subsystem may be used for internal testing andfor development of new or modified programme, daypart or channelgraphics and/or formats. It should preferably have access to thebroadcast servers 180, 185 but only to get access to content data andfor publishing the final production-ready software onto the proofingserver 400.

Embodiments of the present invention can offer an automated broadcastservice with live or pre-recorded content 24 hours a day, 7 days a week,365 days a year. Maintenance, upgrades, data archiving and any otherpotentially disruptive activity should be subordinate to this keyobjective. Channels will need to be updated with new data, the frequencydepending on the content and the channels' requirements. In cases wherethe system does not allow updating and playout simultaneously due tohardware or software restrictions, the update process and acceptabledown time should be documented and agreed in advance.

Referring to FIG. 10, a system for creating, testing and developing newor modified programme, daypart or channel graphics and/or formats andfeatures comprises the steps of:

-   1. Securing log-in to a workstation 1000 at the IBS provider's    domain 105-   2. Creating and/or modifying software-   3. Retrieving content (clips or video files for example) from the    storage server 165-   4. Taking user input test feed from a moderation workstation 600-   5. Testing the new or modified software by running it with the    retrieved content and test feed on the proofing server 400

New features and software developments should preferably be trialled onthe proofing server 400 before being used in live broadcasts. Alsopreferably, the new features and software developments will be testedduring periods when no channels require proofing. Any client softwaremodifications can be trialled by loading software onto a non-productionPC and tested against server components on the proofing server.

It will be understood from the above that the IBS provider's domain 105in this embodiment provides several of the processes which cancollectively be regarded as an asset processor. Apart from the functionof moderating user inputs, all the functions described above can beregarded as part of an asset processor. The domain 105 also provides atleast one of the user input processes which can collectively be regardedas a user input processor. For instance it provides user input displayand editing facilities for moderation 600, 1100.

4. BROADCAST HOSTING DOMAIN 110

In the following description, only one broadcast hosting domain 110 isdescribed but in use it is preferred that there is both a live and astandby broadcast hosting domain, for the reasons previously mentioned.

Referring to FIG. 1, broadly speaking, the broadcast hosting domain 110broadcasts a programme schedule created substantially in real time fromboth pre-programmed scheduled events from the IBS provider's domain 105and real time user inputs received via the network provider's domain100. The final programme schedule can contain both pre-recordedprogrammes or live programmes. To do this, it comprises a scheduler 1200and two IBS servers:

-   -   the VIS 175 for storing unscheduled material, particularly user        inputs    -   the broadcast server 180 for storing scheduled material, content        and static data such as algorithms for processing user inputs,        and daypart definitions

The scheduler 1200 applies the static data in processing unscheduledmaterial, particularly user inputs, which is then used to modifyscheduled material and so put together a broadcast stream from acombination of scheduled and unscheduled material (which can containboth pre-recorded and live material). This might comprise for examplemusic clips in a specified order with overlaid graphics, a live feedfrom a studio or the two used together to make up a programme. Outputfrom the broadcast hosting domain 110, via the broadcast server 180, maybe in the form of a serial digital interface to an uplink facility via adedicated high-speed line or other suitable means.

The following describes just the live broadcast hosting domain 110 butthe standby broadcast hosting domain 115 is the same.

In practice, the two servers 175, 180 support processes as well as dataand this provides the following functionality 170 in the broadcasthosting domain 110:

-   -   scheduling    -   user input validation    -   user feedback    -   optionally, user input moderation        4.1 VIS server 175

Referring to FIG. 11, three of these processes run on the VIS server175. (Only the scheduler runs on the broadcast server 180.)

The VIS 175 provides a repository for all user input data coming fromthe RVIS 155. In many cases the RVIS 155 will be located at the networkprovider's domain 100, as described above, but in practice it maylocated elsewhere, or in some circumstances there may not be a need forthe RVIS 155, all user inputs coming straight to a VIS 175. Data may becopied from the RVIS 155 to the VIS 175 and preferably the user inputdata is copied initially into tables. Preferably the tables containunmoderated lists of various types of user input. In one embodiment,described above, the copying may take place using a mySQL subroutine.Preferably, a VIS 175 will be used across multiple channels. Each VIS175 may have a reasonable number of connections to the IBS provider'sdomain 105 (eg for moderation), and the broadcast server 180 and theRVIS server 155.

Taking firstly the user input validation process 1105, this reads votesand requests as they arrive from the RVIS 155 to the VIS 175, determineswhether the three digit numbers identifying items from a play or cliplist are valid (that is, part of the play list) and places valid votesand requests in the appropriate table (vote or request) in the VISdatabase 1115 depending on what mode the IBS is in. Invalid votes andrequests are discarded.

Since dedications consist of a message and a vote/request, the userinput validation process 1105 also validates the three digit numberportion of the dedication.

Taking secondly the user feedback process 1110, this is triggered to runeach time a user sends a message or interacts in any way with thechannel. Each user making an input receives an immediate acknowledgmentfrom the channel and may receive further responses from the channel.Where a user input has been received at the network provider's domain100 via IVR, the acknowledgement will be provided by an automated voicewhich thanks the user for their contribution. In the case of SMS, amessage will be sent back to the user thanking them for theircontribution and providing any other required information. The messageback to the user is initiated by the user feedback process 1110 runningon the VIS server 175 and executed via the network provider's domain100. In the case of a user input received over the Internet, an emailwould be sent back to the user thanking them for their contribution andproviding any other required information. VIS server 175 is providedwith a Web server 1120 and the email response could be executed via theweb server 1120.

Taking thirdly the moderation process 1100, this is preferably run fromthe IBS provider's domain 105 and moderation has already been describedabove. (Although shown in FIG. 11 as being installed on the VIS server175, the moderation application could in practice be installedelsewhere, for instance in the IBS provider's domain 105.) Briefly,operators can review unmoderated lists of user input stored in the VISdatabase 1115 and approve, reject or modify the input items. Approval(modified or otherwise) may be recorded by copying the input item toanother location in the VIS database 1115. Preferably a flag will alsobe set in the unmoderated list to show that it has been processed.Rejection may merely result in a flag being set in the unmoderated listto show that it has been processed.

Transaction rates from RVIS 155 to VIS 175 may exceed 100 transactionsper second (tps). Coupled with querying from the broadcast server 180and the moderation function, this could reach 200 tps. This rate shouldbe manageable on a relatively small system.

4.2 Broadcast Server 180

Referring to FIGS. 12 and 13, the scheduler application 1200 runs on thebroadcast server 180. The scheduler application 1200 has access to fourtypes of content for scheduling:

-   -   unscheduled events 1300 stored on the VIS database 1115    -   scheduled events 1210 stored on the broadcast server database        1220    -   clips 1215 such as video clips, also stored on the broadcast        server database 1220    -   external feed 1230 such as live video input, which arrives from        a studio or other external source

The unscheduled events 1300 comprise the user inputs stored on the VISdatabase 1115.

Scheduled events 1210 include idents, interstitials, sponsoredprogrammes and advertising. This list is prepared in advance and isscheduled to be broadcast at a specific time. The scheduler 1200processes these events together with the unscheduled events 1300,applying appropriate algorithm(s) and/or daypart definitions 1225, 1205,to create the final broadcast stream with appropriate graphic overlay.

The broadcast elements 1215 as stored include both the clips themselvesand clip lists. Clip lists are the lists of content available for usersto interact with (requests, votes, etc). Clip lists can be prepared inadvance. Clips might also include proforma broadcast elements such astables or game presentations which will be updated for broadcast,according to an appropriate algorithm 1225, in response to user inputs.

Determination of the next file to play, and on-screen prompts, may bedone by issuing a remote query to the VIS database 1115. Preferably aquery will be issued periodically to determine the file to playalgorithmically from the moderated user input lists. More frequently, aquery may be issued to determine the prompts to display, by a simplerquerying of these lists. This may return all the information for theprompt to display. It will also need to update the lists for anyselected prompts to indicate that they have been displayed andprocessed. It is preferred that all access to the VIS database 1115 fromthe broadcast server 180 should be via mySQL subroutines located in theVIS database 1115 so as to minimise network traffic between them and tokeep the broadcast server 180 insulated from the detail of how queriesneed to be run.

The scheduler 1200 continuously looks at unscheduled events 1300 whichhave arrived in the VIS database 1115 and at the scheduled events 1210and selects the next piece of content 1215 to play whether it ispre-recorded or live and the appropriate overlay graphics and sends thisinformation to a playout and graphics engine 1305. The playout andgraphics engine 1305 takes instructions from the scheduler and plays outthe appropriate content with associated graphics. If text or picturemessages have been made for a particular item of content, they will beshown as well.

Once the relevant data is on the broadcast server 180, using the userinputs and any other relevant information contained in the system, atthe end of every piece of content, the scheduler can determine what tobroadcast next. It can incorporate video data (live and pre-recorded),audio data, text, images and graphics to build the final broadcaststream that is then distributed to viewers/listeners.

External feed 1230 is also available to the scheduler. This might supplyfor example advertisements or live news items. Advertisements mightprovide scheduled events and live news items might provide unscheduledevents. For example, advertisements might be stored as scheduled events1210 on the broadcast server database 1220 but they might instead besupplied from an external advertisement server and these can betriggered by the IBS at the appropriate time to play out theadvertisement. Live news items meanwhile might arise as unscheduledexternal events because unscheduled events 1300, particularly votes orrequests, which have arrived in the VIS database 1115 indicate that thenext piece of content should be taken directly from an external livenews source. In this case, the scheduler needs to insert material fromthe live news source as an unscheduled event.

In order to insert externally fed material, the system also comprises atrigger that can be used to trigger input to a broadcast from outsidethe system. In one embodiment a code is inserted into the verticalblanking interval (VBI) to trigger the insertion of materials, forexample advertising breaks. The material can be inserted either byplaying content with the appropriate lines in the VBI or by sending ageneral purpose interface (GPI) to a system which will do the insertion.Such systems are commercially available, such as the Oliver V offered bySoftel Ltd. The second system, using a GPI, is more robust. For examplethe broadcast system could send an appropriate GPI to a Softel Ltd boxat the end of a clip which is played immediately before a proposed adbreak. The GPI could be sent using a digital I/O card, the AdvantechPCI-1750, or the like.

At certain periods during the day there may be only a small number ofinputs from users. In this case, the scheduler may apply a rule causingit to revert to appropriate content from a preset content list andbroadcast that material.

As mentioned above, in order to make scheduling decisions, the schedulerapplication 1200 also has access to daypart definitions 1205 and userinput algorithms 1225, these both being stored on the broadcast serverdatabase 1220. The scheduler application might be run so thatinteractive broadcasting is available 24 hours per day, for time limiteddayparts such as a period of days, hours or minutes, or for anindividual programme.

In an example of a programme for interactive broadcasting, the programmemay start with an introduction, move on to a set of video clips andfinish with a closing session. Different parts of the programme might beavailable for interactivity with users. For example, users might be ableto post messages on screen throughout the programme, post dedications onscreen while specified video clips are playing, and vote or makerequests in relation to the video clips at any time until the closingsession starts.

The scheduler application 1200 will show this programme by schedulingthe introduction and closing session. During the introduction andclosing session, it will poll the VIS database 1115 for any tablescontaining messages. If moderated messages are present in relation tothe relevant channel, they will be scheduled for immediate screening.During the playlist portion of the programme, the scheduler application1200 will additionally poll the VIS database 1115 for any tablescontaining the code identifying a clip. Depending on the current daypartdefinition, such a table might indicate a dedication, a vote or arequest. If there is a message associated with the code, text and/orpicture, then the scheduler application 1200 will schedule screening ofthe message concurrently with the identified clip. If the daypartdefinition indicates that votes are expected, the scheduler application1200 will treat any codes without messages as votes. That is, it willrun a voting algorithm and, usually, play a clip with most votes. If thedaypart definition indicates that requests are expected, the schedulerapplication 1200 will treat any codes without messages as requests. Thatis, it will play the next requested clip from a list.

As well as scheduling user inputs, the scheduler application 1200 willalso be required to post information on screen which users need, such asthe fact that the broadcast is interactive and whether voting is open orclosed. There may also be descriptive or promotional information whichneeds to be shown synchronously with individual clips.

This can be polled from database tables in the broadcast server database1220 in a manner analogous to dealing with user inputs.

In one variation, the unscheduled events 1300 might also comprise freshnews items which a broadcaster has received not from a user but forinstance from a news channel or a news service. This arrangementsupports a service in which users can vote for fresh news or gossipitems to be broadcast as they arise, such as sports results, or they canbe posted automatically as they are received by the broadcaster as partof a programme.

In general, it is functionality running on the broadcast server 180which decodes the video, audio and text and other data and turns it intoa feed to send to the cable head end, satellite uplink or whicheverdistribution method is required by the broadcaster. The broadcast server180 comprises the systems that stream the content through to thedistribution function (ie. the uplink provider). The broadcast server180 is a core part of the system that should be kept running andbroadcasting content even if other parts of the system have gone down.

Preferably the broadcast server 180 performs only the tasks that itneeds to in order to (a) select the files or live video input it needsto play, (b) stream the selected file or live video at the appropriatetime, (c) log its activity, and (d) provide a monitoring and controloverride capability back to human operators. Preferably, there are noregular updates to this server, all such updates being handled by theVIS 175.

In the above, the broadcast server 180 is generally described inrelation to screen-based broadcasts. However, a broadcast may be outputto viewers in one of a number of formats depending on the broadcasters'infrastructure, distribution platform and/or the receiver's system.

Embodiments of the present invention can play out an integratedbroadcast stream in one of a number of analogue and digital formats ofvarying quality, including but not limited to, SDI with embedded audio,SDI with separate AES/EBU audio, analogue component and separateanalogue audio, composite video with separate analogue audio, SVHS withseparate analogue audio, DVI or as an IP based video/audio stream.

Embodiments of the present invention can be designed to work with manybroadcast distribution platforms, including but not limited to analogueor digital satellite, cable or terrestrial, closed broadcast systemssuch as those found in, but not limited to hospitals, hotels and bars,IP networks (TV over IP) and fixed (DSL, cable, fiber) or wireless(Wifi, Wi-Max) narrowband and broadband networks.

The broadcast hosting domain 110 can be deployed in many different waysdepending on each broadcaster's requirements and other issues such as,but not limited to, space in the playout centre, available budgets,bandwidth available for distributing the broadcast, geographicallimitations, technical limitations. The present invention is flexibleenough to accommodate such diverse requirements.

Four examples of how the broadcast hosting domain may be deployed aredescribed below, with reference to FIGS. 1, 11, 12 and 13.

1) Local deployment: In this deployment all components of the broadcasthosting domain 110 are located in the same physical location. Theplayout and graphics engine 1305 may output the broadcast as an SDIstream with embedded audio for distribution via a digital satellitenetwork.

2) Hybrid deployment: In this example the components of the broadcasthosting domain are located in two places, a broadcast centre and a datacentre. The scheduler application 1200, clip table 1215 (which includesall available broadcast elements) and playout and graphics engine 1305reside in the playout centre. The remaining components of the broadcasthosting domain 110 reside in the data centre.

The scheduler 1200 accesses the VIS database 1115 and broadcast serverdatabase 1220 (with the exception of the clip table 1215 which resideswith the scheduler 1200 as described above) via a secure communicationslink such as a DSL or t1 line. The scheduler 1200 decides what should bebroadcast and the playout and graphics engine proceeds to playout theappropriate video, audio and graphics.

In this example the playout and graphics engine 1305 is playout out ananalogue component video signal with separate analogue audio signalwhich are distributed over an analogue cable network.

3) Remote to PC deployment: In this example the scheduler 1200 andplayout and graphics engine 1305 are in the location where the broadcastwill be played out. The rest of the broadcast hosting domain 110components are located in a secure data centre. The scheduler 1200accesses all required VIS 175 information and broadcast database 1220remotely from the data centre via a secure communication link.

The information (such as user inputs 1115, clip table 1215 and daypartdefinition table 1205) is received by the scheduler and given to theplayout and graphics engine 1305 for playout.

In this example the playout and graphic engine 1305 is playing out ananalogue composite video signal and separate analogue audio signal fordistribution over a closed network in a hospital.

4) Remote to STB deployment: In this deployment all components of thebroadcast hosting domain are located in a secure data centre. In theplayout centre there is a Set Top Box capable of receiving andoutputting Windows Media, Real Media or other types of video/audiostreams.

The playout and graphics engine 1305 component of the broadcast hostingdomain 110 outputs the broadcast stream as a Windows Media, Real Mediaor other type of video/audio stream. This is transmitted to the STB inthe playout centre via a standard IP connection. The STB receives thevideo/audio stream and outputs the broadcast. In this example broadcastoutput by the STB is distributed via a broadband connection to viewers'homes.

4.2.1 Algorithms

Clearly the nature of the algorithms which the scheduler 1200 uses inprocessing the user inputs at least partly determine the response of theIBS to user inputs. Examples of simple algorithms that might be used areas follows: Scheduling Algorithm If (current_time + next_clip_time) >=next_scheduled_clip then Send next scheduled clip to playlist Else If(request_count = 0) then Send clip from clip play list Else Send nextrequest End If End If

FIFO

Request arrives

Check last time played−X minutes

Check if already requested In request list−Y minutes

-   -   If not requested Y=0    -   Else Y=next slot

If X+Y>=minimum time between plays

-   -   Write to request play list

Else

-   -   Do not write to request play list

Voting—triggered every N minutes

Every N minutes

Check vote count for top M videos

For each of the M videos

-   -   check last time played−X min    -   check if already in request list+when−Y min    -   If X+Y>min_time put in req list Else drop

Reset counters Request/Voting algorithm If (Requests = False) Do nothingWait until time to count votes If (new_clip >= 1) AND (Requests = False)then Write request to request/vote list Else If vote_counter =minutes_between_votes then Calculate votes, note last vote positionUpdate request list from top with correct # clips Else Do nothing End ifEnd if

Dedications

If dedicated clip is already requested it can get shown with clip (<Xdeds) then

-   -   Do not add clip to request list    -   Add dedication to dedication list

If dedicated clip is not already in the request list

-   -   Put through normal clip validation    -   Add dedication to dedication list

4.2.2 Daypart Definitions

Daypart definitions are mentioned above. They provide rules whichcontrol the behaviour of the scheduler over different time periods. Thetime periods may be more than one day long, in which case for examplethe behaviour of the scheduler might be different at weekends.Alternatively, the time periods may be less than one day long, in whichcase for example the behaviour of the scheduler might be different inthe evenings.

Using daypart definitions, it is possible to trigger the scheduler toschedule items from a different list of available content, givingviewers increased choice and making the dayparts more interesting. Itwould be possible to broadcast an event based channel that promotesevents of a time limited duration, such as the launch of a film or aconsumer exhibition. Each “event” could be broadcast for between onemonth to three months. In the case of dayparts less than a day long, itwould be possible to promote several events each day, by giving eachevent its own daypart. Each daypart could inform viewers about adifferent event and allow different types on interactivity.

Daypart definitions can also be used to determine the mode in which thescheduler is operating. For example at some times of day, user inputscomprising just a three digit code might be treated as a request whileat another time of day the same user input might be treated as a vote.The mode in which the scheduler is operating may cause it to reject sometypes of user input and only accept for example votes and/or messages.

In practice, using daypart definitions to control the behaviour of thescheduler, the same user input could be caused to have quite differenteffects. For example, at some times of day a vote may be a discard voteinstead of a vote in favour of content. In this example, the response ofthe scheduler might be to block any further selection of an item ofcontent which has received most votes. Users would be advised of thecurrent format of an interactive broadcast, and therefore the effecttheir vote could have, by on-screen text triggered by a daypartdefinition at an appropriate time. On-screen text and promos can also beused to advise users in advance that a particular format will be appliedfor the duration of a particular daypart.

A daypart definition will therefore generally contain a time period forapplying the daypart rules, plus the rules (or at least pointers orreferences to the rules) to be applied by the scheduler. These rulesmight for example dictate one or more locations where the schedulerlooks for items to schedule, plus how the scheduler deals with itemsfound in those locations.

Simplified examples of daypart definitions are given below, although itwill be understood that the definitions in practice will be moredetailed and may control additional IBS mechanisms not included below,such as rules for sending immediate one-to-one feedback to the user onreceipt of an input.

Scenario 1:

Live interactive chat show—a host and guests discuss a specific topicwhile viewers express their opinions by sending in text messages. Themessages are commented on and discussed by the host and guests.

The daypart definition for this might contain

-   -   times of day defining a daypart period corresponding to a chat        portion of the show (eg 12:00 to 13:30 Monday to Friday)    -   Rule 1—for scheduling IBS information to users, the scheduler        should access a first database location where items of IBS        information are stored    -   Rule 2—the items of IBS information should be overlaid on a        first specified portion of the screen in turn for a fixed period        of (say) three minutes    -   Rule 3—for scheduling moderated user messages, the scheduler        should only access a database location where moderated messages        are stored    -   Rule 4—the content of each moderated message should be overlaid        on a second specified portion of the screen in turn for a fixed        period of (say) five seconds.    -   Rule 5—if the number of moderated messages stored in the        database goes above an upper threshold, change the “Rule 1”        database location (IBS information) to a first substitute        database location    -   Rule 6—if the number of moderated messages stored in the        database goes below a first lower threshold, change the “Rule 1”        database location (IBS information) to a second substitute        database location    -   Rule 7—if the number of moderated messages stored in the        database goes below a second lower threshold, terminate or        change the daypart definition currently in use    -   Rule 8—five minutes before the end of the daypart period, change        the “Rule 1” database location (IBS information) to a third        substitute database location

This daypart definition enables the scheduler 1200 to give IBSinformation (eg information about the current programme, optionsavailable and telephone numbers to ring) to inform users how to send inmessages, and it enables the scheduler 1200 to display the messages. Italso allows the scheduler 1200 to respond if there are too many or toofew messages, for example by informing users and potentially by givingan incentive to send messages or even by terminating the chat portion ofthe show.

Scenario 2:

Late night dance daypart, playing dance music based on viewers votes.Text and picture messages are also displayed as part of the broadcast.

The daypart definition for this might contain

-   -   times of day defining a daypart period corresponding to a dance        period of a show (eg 23:00 to 02:00 Thursday, Friday and        Saturdays)    -   Rule 1—for scheduling IBS information to users, the scheduler        should access a first database location where items of IBS        information are stored    -   Rule 2—the “Rule 1” items of IBS information should be overlaid        on a first specified portion of the screen in turn for a fixed        period of (say) one minute    -   Rule 3—for scheduling dance music based on user inputs, the        scheduler should access a database location where votes are        stored    -   Rule 4—the scheduler should apply a specified algorithm in        processing the votes to select dance music to schedule    -   Rule 5—for scheduling messages based on user inputs, the        scheduler should access a database location where moderated        messages are stored    -   Rule 6—the content of each moderated message should be overlaid        on a second specified portion of the screen in turn for a fixed        period of (say) five seconds.    -   Rule 7—for scheduling dedications based on user inputs, the        scheduler should access a database location where moderated        dedications are stored    -   Rule 8—the content of each moderated dedication identifying a        piece of music should be overlaid on a third specified portion        of the screen in synchronism with the piece of music for a fixed        period of ten seconds    -   Rule 9—if the number of dedications identifying the same piece        of music goes above a threshold, reduce the “Rule 8” fixed        period to five seconds    -   Rule 10—if the number of moderated messages stored in the        database goes above an upper threshold, change the “Rule 1”        database location (IBS information) to a first substitute        database location    -   Rule 11—five minutes before the end of the daypart period,        change the “Rule 1” database location (IBS information) to a        second substitute database location

This daypart definition enables the scheduler 1200 to inform users howto send in votes and messages, to schedule music in accordance with thevotes and to display the dedications and messages. It allows thescheduler 1200 to respond if there are too many messages but, in thiscase, it does not matter if there are too few messages as the dancemusic will continue to be played in accordance with votes received. The“Rule 2” algorithm can be used to determine what the scheduler 1200 willdo if there are no votes, for example reverting to a default playlist.If one piece of music inspires a lot of dedications, Rule 9 enables thescheduler 1200 to screen them more quickly.

Scenario 3:

Weekend shopping segment—viewers vote for which products they would liketo see shown and either request further information or purchase theproducts via SMS, IVR, a call centre, or an electronic communicationsnetwork, for example the Internet.

The daypart definition for this might contain

-   -   times of day defining a daypart period corresponding to the        shopping segment (eg 08:00 Saturday to 00:00 Sunday)    -   Rule 1—for scheduling IBS information to users, the scheduler        should access a first database location where items of IBS        information are stored    -   Rule 2—the “Rule 1” items of IBS information should be overlaid        on a first specified portion of the screen in turn for a fixed        period of (say) four minutes    -   Rule 3—for scheduling images or video clips of products based on        user inputs, the scheduler should access a database location        where votes are stored    -   Rule 4—the scheduler should apply a first specified algorithm in        processing the votes to select products to show    -   Rule 5—for scheduling information requested in user inputs, the        scheduler should access a database location where information        requests are stored    -   Rule 6—the scheduler should apply a second specified algorithm        in processing the “Rule 5” information requests to select        information to show    -   Rule 7—for processing purchase requests, the scheduler should        access a database location where purchase requests are stored    -   Rule 8—the scheduler should apply a third specified algorithm in        processing the purchase requests firstly to validate the content        of the purchase requests in relation to stock, secondly to check        that relevant stock is still available and thirdly to route the        purchase requests to an appropriate destination    -   Rule 9—for scheduling information to users concerning stock        levels, the scheduler should access a database location where        purchase requests are stored    -   Rule 10—the scheduler should apply a fourth specified algorithm        in processing the purchase requests to select stock level        information to show    -   Rule 11—five minutes before the end of the daypart period,        change the “Rule 1” database location (IBS information) to a        substitute database location

This daypart definition enables the scheduler to inform users about theshopping segment and how to send in information and purchase requests.It allows the scheduler 1200 to respond by displaying requestedinformation. It also allows the scheduler 1200 to run an algorithm inrelation to the purchase requests so that it can display information tousers about remaining stock levels.

It will be understood from the above that the broadcast hosting domain110, 115 in this embodiment provides at least one of the user inputprocesses which can collectively be regarded as a user input processor.For instance it provides user input validation 1105 and feedback tousers 1110 in response to inputs. The daypart definition for Scenario 3above is interesting however in that it shows an example where thesoftware providing the scheduler 1200 can in practice also provide atool for user input processing. That is, rules 7 and 8 trigger thescheduler 1200 to validate and forward purchase requests to anappropriate destination such as a customer service department of anappropriate supplier. Alternatively, the scheduler 1200 could transferthe purchase requests to another application such as the tool for uservalidation 1105.

It will also be understood that the broadcast hosting domain 110, 115 inthis embodiment provides an asset store as mentioned above, by means ofthe broadcast server 180. For instance, as described the broadcastserver 180 stores scheduling criteria as well as encoded video/audiobroadcast elements. The scheduling criteria here comprise in particulardaypart definitions, algorithms and playlists.

Referring to FIG. 14, one possible screen layout is shown. The screenlayout will depend on the programme being broadcast and on the stagereached in the programme, since both factors are likely to requiredifferent numbers of screen elements to be present. As seen in thefigure, the screen elements may be for synchronous or asynchronouspresentation with clips and are likely to comprise any one or more ofthe following:

-   Bug—The graphic logo of a channel. This will often always be on.-   Content Info—information that is displayed at the beginning and end    the content that is being broadcast.-   Sales Ticker—a continuous ticker through which products are promoted    to users. It is preferably asynchronous with the content.-   Text and picture messages—will often be content specific and are    therefore often synchronous with the content. Messages are often    asynchronous.-   Prompts—are designed to prompt users to interact. Content numbers    may be displayed and mixed with lines such as “give us a call” and    “send a message to a mate”. This graphic may run asynchronously to    the content.

All graphic elements can have their colour, location and font changedand can be enabled and disabled, depending on the programners'requirements. Graphic elements may also be imported into the systemusing standard graphic file formats.

5. PLATFORM, FAILOVER AND ARCHIVING

5.1 Platform

Referring to FIG. 15, an outline is shown of platform elements whichmight be used to support an embodiment of the present invention. (In thearrangement of FIG. 15, the network provider's domain 100 is not shownand thus there is no RVIS 155 shown.)

As can be seen, the IBS provider's domain 105 uses a Microsoft Windowsenvironment which sends proofed broadcast materials and schedules forstorage in the broadcast hosting locations 110, 115. In practice, thedelivery of proofed video data to the broadcast hosting locations 110,115 occurs as follows. Video data is encoded and edited as describedabove with reference to FIGS. 2 and 3, using suitable software andworkstations 205, then stored on the storage server 165. The video datathen goes from the storage server 165 to the proofing server 400 forproofing. When proofed, the video data is sent directly from the storageserver 165 to the broadcast servers 180, 185 in the broadcast hostinglocations 110, 115.

Wide area networks 1500 are used between the IBS provider's domain 105and the broadcast hosting domains 110, 115 and local area networks 1505are used within the broadcast hosting domains 110, 115. Communicationsfrom the network provider's domain 100, and moderated user inputs fromthe IBS provider's domain 105, both of which may comprise damagingcontent since these include user inputs which could for example carry avirus, are received at the broadcast hosting locations via a firewall1510.

The server operating system could alternatively be for instance based onthe Apple Mac operating system.

Preferably a dedicated RAID 5 or 0+1 disk array should be used to storethe media files that will be played from the broadcast server 180.Preferably, separate internal mirrored disks should house the operatingsystem, applications and database (such as mySQL).

Tests have shown that a single processor platform performs adequatelyfor one channel but dual processor or other suitable platforms may beused. Whilst it is possible to run multiple channels on a single server,it is preferable not to do so but rather to use one processor platformper channel.

In one embodiment the broadcast server platform comprises a personalcomputer having at least one HDD with MPEG-4 encoded video and encodedaudio for the channel. A Specialised Optibase card is used to decode thevideo and audio data and turn it into a broadcast feed which is thensent into the cable head or satellite uplink.

It might be preferred that each of the broadcast, VIS and RVIS servers180, 175, 155 is dual-processor to enable more effective handling of allof these connections. Concerning the storage server 165, it may bepreferred that this is a network attached storage (NAS) device or, moresimply, a personal computer server with attached disk. Attached storagemight be in RAID 5 or 0+1.

A database is located on the storage server containing local copies ofplaylists, programming decisions, weightings, etc. to enable broadcastasset management. It should preferably also store a table of the storedvideo files on this server. The database may have very low activity. AmySQL database might be suitable.

5.2 Failover

Referring to FIG. 7, in the event of failure affecting the livebroadcast hosting domain 110 but not the standby 115, it is preferableto be able to achieve a switchover from the live to a standby domain 115in the order of five seconds. If the problem is in the broadcast server180 or scheduler application 1200, it is possible to initiatereconfiguration of the previously live VIS 175 to act as backup to thenewly live broadcast hosting domain 115. Hence a switchover proceduremight comprise the following steps:

-   1. Channel monitor 700 shows problem with broadcast-   2. Switch is initiated from the live to the (already synchronised)    standby broadcast hosting domain 115-   3. Alert raised for urgent fix in the previously live broadcast    hosting domain 110-   4. The VIS 175 in the previously live broadcast hosting domain 110    converted to backup to the newly live broadcast hosting domain 115-   5. The previously live broadcast hosting domain 110 is fixed with    on-site spares-   6. Switch is initiated back to the previously live broadcast hosting    domain 110-   7. On-site spares replaced.    5.3 Archiving

Referring to FIG. 8, material can be archived from the data storageprovided in the broadcast hosting domains 110, 115. In particular, olduser inputs, programming data and log files can be archived. For thelive broadcast hosting domain 110, this comprises the steps of:

-   1. Check that the domain 110 is in a state to cope with archiving    (not broadcasting)-   2. Run archive program to transfer data to DVD-   3. When archive is complete and verified, remove DVD and label.-   4. File DVD in appropriate archive storage area

All old data can be removed from relevant servers whilst a broadcastcontinues. Archiving requirements for each server would consist of thefollowing:

-   -   Broadcast server 180—video files no longer required in        schedules; activity information logged to the database (old        schedules and static database information is automatically        removed on a rolling basis as the data is copied from the        proofing server 400—if an old schedule no longer exists in the        proofing server 400, it will no longer exist on the live and        backup broadcast servers 180, 185 after copying.)    -   VIS 175—raw or unmoderated user input; moderated user input    -   RVIS 155—raw or unmoderated user input

All database archiving can be initiated on a regular basis or asrequired, and each system's data is independent of others. There is norequirement even for live and backup to be in sync as far as archivingis concerned.

Database data will be removed via a mySQL subroutine that can beinitiated on a regular basis—for example daily for user input and weeklyfor activity logging. Particular attention should be paid to the needfor offline retention of data either for analytical or auditingpurposes, or to respond to client issues. Options for this include: (a)a further online mySQL database, and (b) export files compressed todisk. Such database data could be stored ultimately on CD or DVD. ThemySQL subroutine which is set up to copy from VIS 175 to VIS 195 willhandle the removal of data from a backup VIS 195. Deletes from the RVIS155 should not be copied to the VISs 175, 195.

Video file data can be removed in a similar way—regularly or on requestvia a script. This script should query the database first, however, toensure that no video files are removed which exist in the current orfuture schedules. Alternately, video files could be removed at specifiedpoints in a scheduling process which avoid removing files stillrequired.

Overall, the IBS thus provides a flexible interactive platform for assetmanagement and user input processing that also supports real timeinteractivity and may build a broadcast stream in real time fortransmission. The broadcast stream may consist of video, audio, textand/or graphics properly synchronised. The IBS may support pre-recordedcontent as well as a live feed. It also supports interactivity via IVR,SMS, internet, STB and other communication systems through a standardinterface.

A version of the system for streaming over the Internet, for a retail ormobile environment preferably outputs a composite or other appropriatevideo signal. This signal may then be encoded and streamed over abroadband or narrowband network, a closed network or a mobile network.

6. EXAMPLES OF EMBODIMENTS OF THE INVENTION IN USE

The following are examples of possible applications for embodiments ofthe invention.

6.1 Digital Radio

Listeners can send text messages via their mobile phones which can beseen by all other listeners on the text display of the digital radio.The interactivity can be used to receive questions from listeners andthen display some of the answers, let listeners vote for the music theywould like to hear and broadcast information about the songs orprogrammes being broadcast.

If SMS is used for user inputs, the IBS for the digital radio stationcould receive the listener messages in one of two ways: directly in tothe VIS 175 or via a network provider. In either case the numbers can beset up in advance and the viewers notified via promos on the station.

6.2 Broadcast Television

The system of the present invention can be used by television channelsto broadcast on a variety of broadcast systems/platforms including:analogue television, digital television, cable, satellite and DTT. Theinteractivity of the present invention can be used throughout the wholeor part only of a broadcast schedule and for all or only some of thechannels being broadcast, as desired by the programmer. Such channelscan include advertising and sponsorship as well as specific programmes(as desired by the broadcaster).

Viewers can send votes, text messages and picture messages via theirmobile phones or set top box and can vote via premium rate telephony.The messages can be broadcast to be seen by the whole viewer base. Theinteractivity can be used to receive and deliver questions and answersin either direction between presenters and viewers (in a liveprogramme), let viewers vote in a live poll and generally engage viewersin a two way dialogue. Viewers could be asked to vote for topics to beupdated as an overlay to a broadcast, such as selected sports results tobe delivered while they are watching another programme or such updatescould be part of a particular programme.

Viewer messages and dedications could also or alternatively beautomatically posted to a website for all viewers to review at theirleisure. In such an embodiment, the system will have two outputs, afirst output for scheduled broadcast elements for broadcasting and asecond output for processed user inputs such as moderated messages anddedications to be posted to the website. (It will be understood thatthis option can apply not just to broadcast television but to anyembodiment of the invention.)

The level of interactivity may be altered from time to time. During anyperiod of full interactivity users may be able to directly influence theprogramming by voting for the clips that they want to see. Through theirvotes, users watching the channel decide what will play.

The programming can be any video material but preferably is presented inshort segments. Examples of appropriate genres include music videos,movie trailers, adult entertainment, travel, shopping, education,business-to-business and many others.

If the broadcaster desires that only specific parts of the broadcast areto be interactive it is able to limit the interactivity to as many hoursper day as required and can be shown at pre-selected times of the day,for instance using daypart definitions. For instance, it would bepossible to broadcast two six hour dayparts on a channel during thecourse of a twenty four hour period. Each daypart could give viewers adifferent list of clips to choose from and allow different types ofinteractivity. Any viewer who already received the television channelwould be able to receive the six hours interactive music daypart.

If text messaging is used for user inputs, then the television wouldbroadcast to viewers the phone numbers or short codes to which messagesshould be sent. The numbers or short codes would be provided by anetwork provider and set up in advance of the broadcast. These could bepremium SMS and MMS services and the viewers would be charged a fee forsending the messages which would appear on their mobile phone bill. Theviewers know what interactive options are available to them because theyare reminded by promos and text screens which are broadcast with thechannel.

If a set top box remote control is used to provide interactivity thenthe television programme could tell viewers how to use it to interactwith the programme. The interactive functionality could be provided bythe cable operator or other supplier and set up in advance of thebroadcast. This would be a premium interactive service and the viewerswould be charged a fee for sending the messages which would appear ontheir monthly cable bill. The viewer sends a message by entering the settop box application and using the numeric keypad on the remote controlto type a message in the same way that it is done on a mobile phone. Ifthe message is as desired, the viewer then proceeds to send the messageand the set top box sends the message via its return path. When a viewersends a message to the channel, it would first be received by the settop box and then transmitted to the cable operator's interactiveinfrastructure. From there it would be sent to the RVIS 155 and from theRVIS 155 to the VIS 175.

6.3 Business-to-Business Television

In one embodiment the present invention can be used for subscriptionchannels. It enables particular groups to be targeted, for example,dentists, patients in a doctor's waiting room, patrons in a pub and anyother specific group that has a need for targeted information.Interactivity can be used to receive questions from users and to pollthem as to their preferred programmes and features. The smaller thetargeted community, the more critical dialogue is with that community.As in the broadcast television example described above, in addition tobeing broadcast on the channel, viewer comments and questions could alsoor alternatively be put on a dedicated website, a digital or analogueteletext page or other suitable page for the specific community to viewat any time.

This example can be deployed as either a single channel or multiplechannels to multiple locations. In the case of a single channel, it canbe one channel that is broadcast in the waiting rooms of doctors'surgeries across the country. In the case of multiple streams, it can bean entertainment channel broadcast to concert venues with each channellocalised for a particular venue.

6.4 Internet

The system can also be used to broadcast channels or programming overnarrowband and/or broadband Internet, Intranet, Extranet and LANnetworks. These channels can be as interactive as desired and can beapplied to a similarly broad range of content as other broadcastapplications. One Web site could be used both to broadcast the channeland for user interactivity. User inputs could be received at the RVIS155 or directly at the VIS 175.

Typically, because the cost of distribution is lower than in broadcasttelevision, it is possible to launch a bouquet of services catering toniche markets that would otherwise be too small to target economically.

Again, due to the lower cost of distribution multiple interactive VODchannels can be broadcast. The number of channels depends on the numberof internet users requesting content. These channels could containsports or adult content, and each viewer could see the same or differentvideo/audio streams and the same or different viewer interaction (suchas text messages, webcam streams, etc) depending on the requirements ofthe application.

Alternatively, the Internet could be used to field user inputs to abroadcast television channel. The television channel would broadcast aninternet address to which users should point their browsers to interactwith the channel. At this Internet address there will reside a web sitethat supports the desired interaction. This web site should be set up inadvance of the broadcast. An internet-based payment mechanism could beused to charge the viewer for interacting with the channel.

6.5 Retail and Event Based

The system can be used to broadcast within retail environments such asdepartment stores, post offices and shopping centres. Again, any contentcan be used but in this application the emphasis is on promotionalmaterial to encourage users to purchase. The interactivity can be usedto encourage shoppers to enter competitions, to select what productsthey would like to see promoted and to make purchases. In this lastexample of user input, the IBS would respond by passing details to afulfilment house to supply a purchased product.

It is possible to create a free to air shopping channel where viewerseither vote for the products they would like to see put up for sale. Orthe broadcast system can automatically decide what product clips tobroadcast based on the volume of telephone calls the channel isreceiving. SMS could be used by viewers to request more information orto purchase products.

An interactive channel could be narrowcast into a retail chain's storesduring opening hours and seen on televisions placed throughout thestores. It would be possible to create a dedicated channel for eachindividual high street location and customise it to that particularlocation's inventory situation and/or local customer demand.

It is also possible to create an interactive channel dedicated topromoting events. In this case the channels interactivity could be usedby viewers to register their interest in the event and receive moreinformation and/or to purchase tickets for the event. Using theinteractive nature of the channel, for instance the daypart facility,numerous events could be promoted each day.

6.6 Mobile Devices

To broadcast an interactive channel to wireless mobile devices such asPDAs, handheld computers and mobile telephones via 2.5 G and 3 Gplatforms. In this application users can subscribe to various servicesthat will provide them with dedicated interactive channels or daily orhourly video updates in specific genre areas.

One good example is a television based game that can also be broadcastto a mobile device. When a player is not home, but would like toparticipate in the broadcast they may do so using their mobile device.

6.7 Broadcast Booking

As mentioned above, the user making a user input to the IBS preferablyalways receives an acknowledgement. This can be supplied by the userfeedback application 1110 on the VIS server 175. In a broadcast bookingservice, a user might submit a broadcast element which they do not needto see on screen immediately but for which they want to know a broadcasttime. For instance, they might want to know that a message or dedicationthey have submitted firstly is going to be broadcast and secondly isgoing to be broadcast at a fixed time or within a certain time window sothat they can assemble a target audience. To support such a service, theuser feedback application 1110 may be triggered on receipt of a userinput to interact with the scheduler application 1200 to obtainbroadcast confirmation and a broadcast time which can be deliveredimmediately in an acknowledgement to the user of their input.

In any interactive system, response behaviour can clearly affect theuser experience. If a user submits a request for a message to appear onscreen for example, that user will appreciate either immediately knowingthe broadcast time as mentioned above, or seeing the message appearingpromptly on screen. In either case, the interactive system preferablydemonstrates a timely response to the user. In general, embodiments ofthe present invention have the advantage that they can present asubstantially realtime response to users, from the time that the userdelivers an input to the time that the user receives a response.However, the response time will usually be governed in practice byvarious factors, such as the volume of user input at the time, the typeof user input and how the user input is displayed. For example withvoting, all votes might be tabulated at the end of each clipirrespective of how many votes there are. With messages, if there is ahigh volume and the IBS applies a rule that they are therefore displayedfor five seconds each instead of ten seconds, the response time willdeteriorate. However, embodiments of the present invention can usuallymeet a target response time of the order of ten minutes or less, insubstantially all circumstances. “Of the order of” means here “within acouple of minutes of”. In some circumstances, embodiments of the presentinvention can meet a target response time of two minutes or less, oreven ten seconds or less, and can thus appear to give an immediateresponse to user input.

Response time in this context means the time between receipt of a userinput and a response by the system based on the user input (either onscreen or via return communication). Usually, this will mean thescheduler application 1200 also completes a scheduling operation inrelation to the user input. The completion of a scheduling operationputs the system in a position to show a response to the user based onthe user input. The response shown might take different forms, such astransmitting scheduling information in reply to the user input oractually broadcasting a broadcast element based on the user input.

6.8 Personalisation

In another embodiment it would be possible to create on demandpersonalised channels so that viewers could see what they want when theywant. This could be a single channel broadcast to all viewers (whichcould be driven by viewers' votes, for example) or a different channelfor each viewer based on their specific requests.

6.9 Asset Management

In another embodiment it would be possible to use functionalityprimarily described above as being in the IBS Provider's domain 105,supported by an asset store equivalent to the broadcast server 180, onits own to perform the asset management of an existing or new channel.It could perform the following tasks: encoding and storing broadcastmaterials, programme scheduling and finally transferring broadcastmaterials to a broadcast platform. It could also be responsible forretrieving logs and archiving broadcast materials and programmingschedules.

6.10 Interactive Gaming

In another embodiment it would be possible to use the interactive natureof the system to broadcast a single or multiplayer game, the results ofwhich are seen on the screen, that viewers play via one or othercommunication network (SMS or IVR for example). In this example, theuser input processor extracts data from one or more user inputs andcreates or updates a proforma broadcast element which provides a currenton-screen version of the game. The proforma broadcast element could beloaded via the asset manager using the storage server 165 and suppliedto the broadcast server 180 for use in a broadcast. It can then beselected by the scheduler 1200 at broadcast time and updatedalgorithmically by a function of the scheduler 1200 acting as part ofthe user input processor.

The interactive game can be a community based game wherein all viewerssee the same channel and many players can play at one time. It canalternatively be a one to one game where each viewer is playing thecomputer of one other player and as such multiple channels of the gameare output at the same time.

6.11 User Input Moderation, Analysis and Aggregation

In another embodiment it would be possible to use the RVIS 155 and VIS175 on their own to receive user input and perform moderation, analysisand aggregation functions. The user input can then be fed into abroadcast server or used for a non-broadcast application such as amarketing campaign or retail promotion.

6.12 Community Based Interactive Games

In another embodiment it would be possible to use the system tobroadcast interactive community based games. These are games where acommunity of viewers, either in teams or as individuals, plays a gamethat is broadcast for all viewers to see. Such games encourage viewersto not only watch but to interact and participate directly. This resultsin higher levels of consumer satisfaction and creates a much strongersense of community that can be further exploited by online activity andone-to-one marketing.

The community in question could be made up of viewers in their homes, inwhich case a single channel would be broadcast to all homes. Eachcommunity could also be made up of patrons in a pub, where multiplestreams would be broadcast, one to each pub.

6.13 Leisure and Hospitality Based

In another embodiment it would be possible to create an interactivechannel for a hotel, pub or other hospitality environment. Theinteractive nature of the channel means that the channel is controlledby the patrons in the pub or club. Patrons experience a channel thatenables them to select the content they want to see, and also expresstheir views and opinions about any topic, by sending SMS messages. Thiscould be a single channel broadcast to all locations, a differentchannel broadcast to each location or even a different channel broadcastto each viewer, depending on the requirement of the application.

6.14 Closed Broadcast Systems

In another embodiment the present invention can be used to creatededicated interactive channels for closed broadcast systems such asthose found in, but not limited to, hotels and hospitals. The channelwould be controlled by the hospital patients or hotel guests who wouldcontrol the content that is broadcast and be able to send text messagesor other interactive input that would be seen by all viewers.

In the case of a single channel this could be described as a communityVOD channel. In the case of multiple channels each hotel room or eachhospital ward could receive a different channel based on the viewers'choices.

6.15 TV over IP

In another embodiment, the present invention can be used to create andbroadcast an interactive channel over an IP network. Such a TV over IPchannel would enable a broadcaster to reach a very large audience costeffectively both through their personal computers and their televisions.This could be used to broadcast a single channel to a large audience ormultiple channels to multiple smaller audiences.

6.16 Video on Demand

In another embodiment, the present invention can be used to create aVideo on Demand system where the content that is requested by theviewers is immediately broadcast by the playout and graphics engine 1305together with viewer input received from the VIS 175. The number ofchannels broadcast depends on the number of viewers at any particulartime.

6.17 Viewer Input Processor

In another embodiment of the present invention, the broadcast hostingdomain 110 can be deployed without the playout and graphics engine 1305.In this case, an external playout and graphics engine is used whichreceives its instructions from the scheduler 1200. So while theinvention is processing the viewer input and still scheduling the viewerinput, clips or both, the actual graphics and playout is done by anexternal system. This is useful in cases where a broadcaster already hasan existing playout and/or graphics engine and only requires the viewerinput to be processed and schedules created.

7. MULTIPLE STREAM EMBODIMENTS

Referring to FIGS. 16 to 19, as mentioned above in relation to severalof the examples given in Section 6, embodiments of the present inventionare not limited to dealing with single broadcast channels but can alsobe used to playout multiple interactive channels. Each of the multiplechannels can be allocated to a different service or they can offerdifferent parts of the same service. Each of the multiple channels canbe broadcast to the same location, for aggregation and inclusion inanother broadcast, or to different locations such as individual homesand/or pubs.

Further, the multiple channels can each:

-   -   be unique, having both different video/audio content and        different viewer interactivity    -   share the same viewer interactivity but have different        video/audio content, for example in the case of a community        based service in which each community can choose different        video/audio content but will see the same viewer interactivity,    -   share the same video/audio content but have different viewer        interactivity per channel.

Each channel will effectively have its own dedicated RVIS 155 and thefunctionality 150 for user input sorting and data storage 155 providedin the network provider's domain 100 needs to adapted to sort userinputs by channel and to direct the user inputs to the correct RVIS 155.Such sorting can be provided in much the same way as described above forsorting user inputs by type. For example, different channels might beallocated different telephone numbers for users to call.

The components of the broadcast hosting domain 110 will generally belocated differently when multiple channels are to be supported. They mayall reside on the same physical machine or reside on two or moremachines, depending on the desired implementation. For example, eachchannel will usually be provided with its own scheduler application1200, clip table 1215 (which includes all available broadcast elements)and playout and graphics engine 1305 and these may be located togetherat the point of broadcast or “playout centre”. Other aspects of thebroadcast hosting domain 110 however may be located remotely from theplayout centre, at a facility shared amongst many channels. Embodimentsof the present invention are flexible enough to support severaldifferent implementations for accommodating multiple channels.

Four examples of how parts of the broadcast hosting domain 110 may belocated to broadcast multiple channels are described below. In eachexample it is assumed that there exists an RVIS 175 for each channelthat is broadcast.

1) Multiple Channels with Local Deployment:

Referring to FIG. 16, in this deployment all components of the broadcasthosting domain 110 are located in the playout center for each channel.The whole broadcast hosting domain 110 is effectively reproduced foreach different channel. This example is useful in cases where multipleversions of the same channel are required, each broadcast to a differentgeographic region. In this case the video/audio could be the same oneach channel, but the viewer interaction will be region specific.

2) Multiple Channels with Hybrid Local/Remote Deployment:

Referring to FIG. 17, in this example, the components of the broadcasthosting domain 110 are divided as follows: the scheduler application1200, clip table 1215 (which includes all available broadcast elements)and playout and graphics engine 1305 reside in one location, forinstance the playout centre, and the remaining components of thebroadcast hosting domain 110 reside at a second location that may alsohouse the RVIS 175. Thus, apart from the clip table 1215, the broadcastserver database 1220 resides at the second location.

At the time of broadcast, the scheduler 1200 accesses the VIS database1115 and broadcast server database 1220 via a secure communications linksuch as a DSL or t1 line. The scheduler 1200 decides what should bebroadcast and the playout and graphics engine 1305 proceeds to playoutthe appropriate video, audio and graphics locally.

As seen in FIG. 17, the scheduler application 1200, clip table 1215 andplayout and graphics engine 1305 must be replicated for each channel.This implementation is useful in a situation where each channel isreceived in a different physical location, such as a pub. In this caseeach pub may be voting for music or sports clips and send text messagesfor display on the screen. With this implementation each pub receives adedicated channel that is specific to the patrons in it at thatparticular time—a community VOD service.

3) Multiple Channels with Remote to PC Deployment:

Referring to FIG. 18, in this example just the scheduler 1200 andplayout and graphics engine 1305 are in the location from where abroadcast will be played out. The rest of the broadcast hosting domain110 components are located in a different location. The scheduler 1200accesses the VIS 175 and broadcast database 1220 for all requiredinformation remotely from the playout centre via a secure communicationlink. In this arrangement, just the scheduler 1200 and playout andgraphics engine 1305 must be reproduced at the playout centre for eachchannel.

This implementation is useful in a business to business channel thatneeds to be seen in multiple locations. For example if an automobiledealership wanted to broadcast a channel to each of its locations, withthe same video and viewer interaction so that viewers in differentlocations can exchange experiences and knowledge, then thisimplementation could be used.

4) Multiple Channels with Remote to STB Deployment:

Referring to FIG. 19, in this deployment all components of the broadcasthosting domain are located in the same location, and all channels areplayed out from that location. In the place where the channels areactually viewed, there is a set top box capable of receiving andoutputting Windows Media, Real Media or other types of video/audiostreams.

The playout and graphics engine 1305 component of the broadcast hostingdomain 110 outputs multiple broadcast streams (as many as are requiredby the application) as Windows Media, Real Media or other type ofvideo/audio stream. This is transmitted to the STBs via a standard IPconnection. The STBs receive the video/audio stream and output thebroadcast.

This implementation could be used for an interactive video on demand(VOD) service that is broadcast direct to viewers' homes. In thisapplication multiple broadcast outputs are distributed via broadbandconnections to viewers' homes. Viewers each watch different video/audio(whichever programmes they selected) but they all see the same viewerinteraction. So although they are watching different content, they arestill interacting with each other via text or picture messages on thescreen. Although each member of the community is watching somethingdifferent, they are still behaving like a community.

It should be noted that, for the purposes of the present specification,the word “comprising” is intended to be interpreted, unless the contextindicates otherwise, so as to include for instance at least the meaningof either of the following phrases: “consisting solely of” and“including amongst other things”.

It will be understood that embodiments of the present invention may besupported by platform of various types and configurations. Thedistribution of software and data storage across platform may bedifferent from that described above. Further, the presence of theplatform is not essential to an embodiment of the invention. Anembodiment of the present invention might therefore comprise softwarerecorded onto one or more data carriers, or embodied as a signal, forloading onto suitable platform for use.

1. A scheduling system for use in broadcasting comprising: i) ascheduler for selecting and scheduling broadcast elements forbroadcasting; and ii) a user input data store for storing user inputdata in which the scheduler is adapted to access the user input datastore and to schedule broadcast elements, the scheduling of one or morebroadcast elements being at least partially determined by stored userinput data.
 2. A scheduling system according to claim 1 wherein, in use,the user input data store stores one or more user inputs.
 3. Ascheduling system according to either one of the preceding claimswherein, in use, the user input data comprises data relating to userinputs.
 4. A scheduling system according to any one of the precedingclaims wherein, in use, stored user input data comprises one or morebroadcast elements.
 5. A scheduling system according to any one of thepreceding claims wherein, in use, stored user input data identifies oneor more broadcast elements.
 6. A scheduling system according to claim 5wherein at least one identified broadcast element comprises an item froma playlist.
 7. A scheduling system according to either one of claims 5or 6 wherein at least one identified broadcast element comprisesmaterial sourced externally to the broadcasting system.
 8. A schedulingsystem according to claim 7 wherein at least one identified broadcastelement comprises live material.
 9. A scheduling system according to anyone of the preceding claims which further comprises an asset store forstoring broadcast elements to be scheduled by the scheduler.
 10. Ascheduling system according to claim 9 wherein the asset store isadapted to store data relating to the broadcast elements, in addition tostoring broadcast elements.
 11. A scheduling system according to any oneof the preceding claims which further comprises a user input processorfor processing user inputs.
 12. A scheduling system according to claim11 wherein, in use, at least one user input comprises a broadcastelement and the user input processor comprises an editing tool for usein editing broadcast elements.
 13. A scheduling system according eitherone of claims 11 or 12 wherein the user input processor is adapted tosort user input data according to type.
 14. A scheduling systemaccording to any one of claims 11, 12 or 13, for use in supporting morethan one broadcast channel during the same broadcast period, wherein theuser input processor is adapted to sort user input data according tochannel.
 15. A scheduling system according to any one of claims 11 to 14wherein the user input processor is adapted to parse user input data.16. A scheduling system according to any one of claims 11 to 15 wherein,in use, stored user input data identifies at least one broadcastelement, and wherein the user input processor is adapted to measure anumber of times said broadcast element is so identified.
 17. Ascheduling system according to claim 16 wherein the scheduler is adaptedto rank broadcast elements in accordance with the number of times theelements are so identified.
 18. A scheduling system according to any oneof claims 11 to 17 wherein, in use, the user input processor isconnected to deliver processed user inputs for storage in the user inputdata store for use by the scheduler in scheduling broadcast elements.19. A scheduling system according to any one of claims 11 to 18 whereinthe system is provided with a first output for scheduled broadcastelements for broadcasting and a second output for processed user inputsand/or broadcast elements.
 20. A scheduling system according to any oneof the preceding claims, further comprising time dependent control meansto control the action of the scheduler according to time period.
 21. Ascheduling system according to claim 20 wherein the time periodcomprises part of a day, such that the action of the scheduler can becontrolled to be different at different times of day.
 22. A schedulingsystem according to claim 20 wherein the time period comprises one ormore days, such that the action of the scheduler can be adjusted to bedifferent on at least two different days.
 23. A scheduling systemaccording to any one of claims 20, 21 or 22 wherein the scheduler isadapted to select and schedule broadcast elements, and wherein the timedependent control means is adapted to control the selection of said oneor more broadcast elements in a time dependent manner.
 24. A schedulingsystem according to any one of claims 20 to 23 wherein the scheduler isadapted to schedule broadcast elements by applying at least one rule,and wherein the time dependent control means is adapted to control therule or rules applied in a time dependent manner.
 25. A schedulingsystem according to any one of the preceding claims adapted forconnection to a communication system for receiving user inputs.
 26. Ascheduling system according to claim 25 having a response time of theorder of ten minutes between receipt of a user input and delivery of aresponse which is at least partly dependent on the result of ascheduling operation by the scheduler in relation to the received userinput.
 27. A scheduling system according to claim 26 wherein saiddelivery of a response comprises broadcasting of a broadcast element.28. A scheduling system according to claim 26 wherein said delivery of aresponse comprises the output of a communication in reply to the userinput.
 29. A broadcast assembly system for assembling broadcast elementsfor broadcast, the system comprising an asset store for storing one ormore broadcast elements, and an asset processor for processing broadcastelements, wherein the asset store, in use, stores at least one rule oralgorithm for use in assembling broadcast elements for broadcast and theasset processor provides at least one tool for processing broadcastelements by editing.
 30. A broadcast assembly system according to claim29, the system further comprising a scheduler for assembling broadcastelements by scheduling.
 31. A broadcast assembly system according toeither one of claims 29 or 30 wherein at least one stored rule oralgorithm comprises a scheduling criterion for use in schedulingbroadcast elements for broadcast.
 32. A broadcast assembly systemaccording to claim 31 wherein the scheduling criterion comprises a ruleor algorithm for responding to at least one user input.
 33. A broadcastassembly system according to either one of claims 31 or 32, wherein theasset processor comprises means to create or modify at least onescheduling criterion.
 34. A broadcast assembly system according to anyone of claims 32 to 33 wherein at least one stored rule or algorithm istime dependent.
 35. A broadcast assembly system according to any one ofclaims 29 to 34, wherein the asset processor comprises means forcreating or modifying one or more broadcast elements.
 36. An interactivegaming system comprising a broadcast assembly system according to claim35.
 37. A broadcast assembly system according to any one of claims 32 to36, further comprising a user input processor, and wherein thescheduling criterion comprises a rule or algorithm for responding toprocessed user inputs.
 38. A broadcasting system comprising: i) an assetstore for storing broadcast elements; ii) a user input data store forstoring user input data; iii) an asset processor for processingbroadcast elements; and iv) a user input processor for processing userinputs, wherein the user input processor is adapted to process userinput to provide user input data for storage in the user input datastore and the asset processor is adapted to process broadcast elementsfor storage in the asset store.
 39. A broadcasting system according toclaim 38 wherein the asset processor comprises an encoder for encodingbroadcast elements.
 40. A broadcasting system according to either one ofclaims 38 or 39 wherein the asset processor comprises an editing toolfor editing broadcast elements.
 41. A broadcasting system according toany one of claims 38 to 40 wherein the asset processor comprises aprogramming tool for programming data and/or processes relating tobroadcast elements.
 42. A broadcasting system according to any one ofclaims 38 to 41 wherein the asset processor comprises a programming toolfor programming scheduling criteria.
 43. A broadcasting system accordingto any one of claims 38 to 42 wherein, in use, stored user input datacomprises at least one broadcast element.
 44. A broadcasting systemaccording to any one of claims 38 to 43 arranged to provide more thanone channel for broadcasting broadcast elements.
 45. A broadcastingsystem according to claim 44 arranged such that two or more channelseach carry a unique set of broadcast elements.
 46. A broadcasting systemaccording to claim 44 arranged such that two or more channels share atleast one broadcast element from the asset store.
 47. A broadcastingsystem according to claim 44 arranged such that two or more channelsshare at least one broadcast element from stored user input data.
 48. Abroadcasting system for supporting more than one independentlyinteractive broadcasting channel.
 49. A user input processor for usewith a broadcasting system according to any one of claims 38 to 48,having an input for receiving user inputs, at least one processing toolfor processing received user inputs, a first output for processed userinputs for use by the broadcasting system in scheduling broadcastelements and a second output for processed user inputs.
 50. A user inputprocessor according to claim 49 wherein the second output is adapted forconnection to the Internet.
 51. A user input processor according toeither one of claims 49 or 50, for use in supporting more than onebroadcast channel during the same broadcast period, wherein the userinput processor is adapted to sort user inputs according to channel. 52.A method of broadcasting, said method comprising the steps of: i)receiving a list of broadcast elements; ii) receiving a user inputrelating to at least one broadcast element, and iii) responding to thereceived user input.
 53. A method according to claim 52 wherein areceived user input comprises at least one broadcast element in additionto the listed broadcast elements.
 54. A method according to either oneof claims 52 or 53 wherein a received user input comprises at least oneidentifier for a broadcast element from the list.
 55. A method accordingto either one of claims 53 or 54 wherein step iii) comprisesbroadcasting the additional broadcast element together with at least onebroadcast element from the list.
 56. A method according to any one ofclaims 52 to 55 wherein step iii) comprises outputting a reply to theuser input.
 57. A method according to claims 53 and 56 wherein saidreply comprises an estimated broadcast time for the additional broadcastelement.
 58. A method according to any one of claims 52 to 57 whereinstep iii) comprises re-ordering the list of broadcast elements.
 59. Amethod according to any one of claims 52 to 58 wherein step iii) isperformed in an hour or less of step ii).
 60. A method according to anyone of claims 52 to 59 wherein step iii) is performed in ten minutes orless after step ii).
 61. A method according to any one of claims 52 to59 wherein step iii) is performed in two minutes or less after step ii).62. A method according to any one of claims 52 to 59 wherein step iii)is performed in ten seconds or less after step ii).
 63. A methodaccording to any one of claims 52 to 62, further comprising the stepsof: iv) receiving at least one user input identifying at least one ofthe broadcast elements on the list; and v) generating a re-ordered listof programme broadcast from said list, in accordance with the at leastone user input.
 64. A method of assembling broadcast elements forbroadcasting, said method comprising the steps of: i) processing atleast one broadcast element and loading the processed broadcast elementto an asset store; ii) receiving, via a user input, data relating to atleast one broadcast element in the asset store; and iii) storing one ormore rules or algorithms for use in assembling a set of broadcastelements for broadcast in accordance with received data.
 65. A methodaccording to claim 64, further comprising the step of assembling a setof broadcast elements for broadcast in accordance with received data andat least one stored rule or algorithm.
 66. A method according to eitherone of claims 64 or 65 wherein at least one stored rule or algorithm istime dependent such that an assembled set of broadcast elements isdifferent at different times.
 67. A method according to any one ofclaims 64 to 66, further comprising the step of receiving, via a userinput, at least one broadcast element, and wherein an assembled set ofbroadcast elements comprises at least one broadcast element received viaa user input.
 68. A method according to any one of claims 64 to 67 whichfurther comprises the step of broadcasting an assembled set.